Re: Avoiding 'master' nomenclature

[Jeff King <peff@peff.net>]

On Wed, Jul 29, 2020 at 02:20:07PM -0700, Linus Torvalds wrote:

> I use that prepare-commit-msg hook to do that.
> 
> I *could* have done that for branch names too, but that is something
> that git has done right for the last 15+ years, so I never had to
> worry or think about it.

Yeah, I think that "just use a hook" is not the right response here.
Hooks are great for making hard or uncommon things possible, but we
should still be making easy things easy. If tweaking this part of the
merge msg in a standard way is something many people want to do, it's
much friendlier for us to provide a config option that does that.

> But a generic replacement (or generation) machinery for the whole line
> would be lovely. And then perhaps just _default_ that regex to be the
> equivalent of
> 
>    sed 's/ into master$//'
> 
> would work really well not just for the branch name prettification,
> but also for things like that "internal vs external hostnames".

This is an interesting middle ground. I'm a little iffy on it just
because it complicates the very simple case of "should I mention the
destination branch", which is what I'd expect most people to care about.
That it also solves your "tweak the source branch" problem is
interesting, but I'm not sure how many people will care (i.e., enough to
justify the extra complication).

> >   2. Optionally a repository created with "git init" could copy its
> >      init.defaultBranch into merge.suppressDest. And likewise a clone
> >      might copy the remote HEAD into that variable. I'm not sure if that
> >      is worth doing or not, but it would restore the original behavior
> >      for the most part.
> 
> Well, the real objection I have to that commit 489947cee5 is that it
> breaks existing users workflow.

I'm not entirely onboard with the characterization of "breaking
workflows". Yes, the result is _different_, but it's mostly a matter of
aesthetics. I'd be more convinced it was a breakage if we were somehow
leaking information about the workflows. E.g., if you merge on a
detached HEAD and then fast-forward your branch to match and you get an
ugly "into HEAD", that might be bad. But nothing changed there (we do
give you the ugly "into HEAD" ;) ). The case that changed is conveying
the same information as before, just more verbosely (by saying the
branch name instead of implying it by omission).

It may be a matter of perspective / opinion, though. And I don't know
that we even need to come to an agreement on it. Whether we treat it as
a feature to suppress the mention of the destination branch, or a
bug-fix to correct a regression, the end result is the same (and to be
clear, I'm on board with doing it in a way that defaults to handling
"master", which is a key part of those two things being equivalent).

-Peff