Re: Avoiding 'master' nomenclature

From: Jeff King <peff@peff.net>
Date: Jul 30, 2020, 00:29 UTC
Message-ID: <20200730002944.GB2996059@coredump.intra.peff.net>
In-Reply-To: <CAHk-=wg7r=y_tYpWuRwNFP0JU5D4g=UN1puCzkvQP4bey0-Hmw@mail.gmail.com>

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

Show 5 quoted lines

> 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.

Show 8 quoted lines

> 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).

Show 8 quoted lines

> >   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