Re: [PATCH v3 0/2] fmt-merge-msg: selectively suppress "into <branch>"

> On Thu, Jul 30, 2020 at 07:04:15PM -0700, Junio C Hamano wrote:
>
> > You'd rather want to "lie" about the destination branch while
> > redoing these merges, perhaps with
> >
> > 	$ git merge --pretend-dest=jch topic-name
> >
> > with your HEAD detached, and tell fmt-merge-msg to pretend that the
> > merge is being made into jch branch.  And that is outside the scope
> > of this patch, though it might be a good #leftoverbits candidate.
>
> Since nobody really asked for it, it may make sense to wait for such a
> feature. After all, this is the just the starting text we put into the
> merge message. You are always free to add the pretend branch yourself in
> the editor.
>
> > >   - should "master" be in the list even if you configure a value? That
> > >     would do the wrong thing if you have a non-integration master, but
> > >     that seems unlikely. And it would do the right thing if somebody
> > >     later puts "main" in merge.suppressDest, but still occasionally
> > >     works with "master" repos (where "right" is defined as "what they
> > >     probably wanted", but it is perhaps a bit magical).
> >
> > If you configure, you can configure it fully without manually
> > clearing first.  If you do not configure, you get a backward
> > compatible default.  I think that is the only sensible semantics.
> >
> > Besides, I thought we were aiming to make 'master' less special.
> > When a user already has a concrete list of things to use shorter
> > merge title for, why should 'master' be magically added to the list
> > and force the user to explicitly clear it?  I do not think that
> > makes much sense.
>
> It's magic-ness would be purely for backwards compatibility. IMHO
> maintaining exact behavior with respect to this particular case was not
> a big deal, but clearly Linus disagrees. But the "do the right thing
> above" I mentioned above is "do the right thing even if the user _did_
> switch their config to a new name, but forgot that they sometimes are
> working with old repos". So it is perhaps an even weaker reason.

> > >   - what's the plan if we do switch init.defaultBranch to "main"? Would
> > >     we add default_branch() to the list of defaults alongside "master",
> > >     or just add "main", or just leave it and let people configure
> > >     independently? It doesn't need to be decided now, but maybe worth
> > >     thinking about.
> > [...quite reasonable analysis that I agree with...]
> >
> > In any case, I do not think I want to see more reliance of the
> > notion that there always is one and only one single special branch
> > in the repository, so if we can get away without it, that would be
> > more preferrable.
>
> Yeah, if the plan is to stop here then I'm OK with that. That makes
> "master" special for historical reasons, but "main" or whatever never
> got this special treatment by default. People have the ability to
> configure if they choose, or they may not care either way.
>
> We might get a feature request later that says "gee, I wish we did this
> for 'main' by default without me having to configure it", but we can
> cross that bridge when we come to it.
>
> -Peff