Git Mailing List Archive on lore.kernel.org
 help / color / Atom feed
From: "Michal Suchánek" <msuchanek@suse.de>
To: Taylor Blau <me@ttaylorr.com>
Cc: Jeff King <peff@peff.net>, Junio C Hamano <gitster@pobox.com>,
	git@vger.kernel.org
Subject: Re: [PATCH v3 0/2] fmt-merge-msg: selectively suppress "into <branch>"
Date: Sat, 1 Aug 2020 09:15:20 +0200
Message-ID: <20200801071520.GD32107@kitsune.suse.cz> (raw)
In-Reply-To: <20200731200306.GB3409@syl.lan>

On Fri, Jul 31, 2020 at 04:03:06PM -0400, Taylor Blau wrote:
> 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.
> 

IMHO this is way better than spome magic variable that you ahve to
assign magic value for it to have teh value you assign. Seen this in
systemd and it is not very nice to deal with.

Thanks

Michal

  parent reply index

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-29 19:44 Avoiding 'master' nomenclature Linus Torvalds
2020-07-29 20:04 ` Junio C Hamano
2020-07-29 20:23   ` Linus Torvalds
2020-07-29 20:38     ` Jonathan Nieder
2020-07-29 20:46       ` Linus Torvalds
2020-07-29 20:56         ` Linus Torvalds
2020-07-30  8:17       ` lego_12239
2020-07-31  0:57         ` Jeff King
2020-07-31  8:19           ` Oleg
2020-07-29 20:40     ` Linus Torvalds
2020-07-29 20:58       ` Jeff King
2020-07-29 21:20         ` Linus Torvalds
2020-07-30  0:29           ` Jeff King
2020-07-30  0:44             ` Linus Torvalds
2020-07-30  0:52               ` Jeff King
2020-07-30  0:57                 ` Linus Torvalds
2020-07-31  0:44                   ` Jeff King
2020-07-29 21:25         ` Junio C Hamano
2020-07-29 22:50           ` Junio C Hamano
2020-07-30  0:14             ` Jeff King
2020-07-30  0:23               ` Linus Torvalds
2020-07-30 10:11                 ` Michal Suchánek
2020-07-30  0:31               ` Jeff King
2020-07-30  0:36             ` Junio C Hamano
2020-07-30 18:02               ` [PATCH v3 0/2] fmt-merge-msg: selectively suppress "into <branch>" Junio C Hamano
2020-07-30 18:02                 ` [PATCH v3 1/2] Revert "fmt-merge-msg: stop treating `master` specially" Junio C Hamano
2020-07-30 19:10                   ` Eric Sunshine
2020-07-30 19:40                     ` Junio C Hamano
2020-07-30 18:02                 ` [PATCH v3 2/2] fmt-merge-msg: allow merge destination to be omitted again Junio C Hamano
2020-07-31  0:42                 ` [PATCH v3 0/2] fmt-merge-msg: selectively suppress "into <branch>" Jeff King
2020-07-31  2:04                   ` Junio C Hamano
2020-07-31  2:22                     ` Jeff King
2020-07-31 20:03                       ` Taylor Blau
2020-07-31 20:12                         ` Junio C Hamano
2020-07-31 20:17                           ` Taylor Blau
2020-08-01  7:15                         ` Michal Suchánek [this message]
2020-08-10 11:53               ` Avoiding 'master' nomenclature Johannes Schindelin
2020-08-10 15:45                 ` Junio C Hamano
2020-08-11  2:39                   ` Johannes Schindelin
2020-08-12  0:30                     ` Junio C Hamano
2020-07-29 20:40     ` Junio C Hamano
2020-07-29 20:51       ` Linus Torvalds

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200801071520.GD32107@kitsune.suse.cz \
    --to=msuchanek@suse.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=me@ttaylorr.com \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Git Mailing List Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/git/0 git/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 git git/ https://lore.kernel.org/git \
		git@vger.kernel.org
	public-inbox-index git

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.git


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git