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

> On Thu, Jul 30, 2020 at 10:22:17PM -0400, Jeff King wrote:
> > 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.
> 
> I think that you could do this without treating 'master' as specially by
> making 'merge.suppressDest' contain the value of 'init.defaultBranch'
> (unless set otherwise).
> 
> This gets tricky when the fall-back value for 'init.defaultBranch'
> changes, though. If it were to go from 'master' -> 'main', you'd want to
> have both of those defaults in your 'merge.suppressDest' list, to avoid
> breaking clients who still use 'master' (and expect 'into master' not to
> show up in their merges).
> 
> So, I guess the rule would be: 'merge.suppressDest' contains the value
> of 'init.defaultBranch' (or its default value) along with any previous
> default values for 'init.defaultBranch', unless specified otherwise.
>