Git Mailing List Archive on lore.kernel.org
 help / color / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Jeff King <peff@peff.net>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Git List Mailing <git@vger.kernel.org>
Subject: Re: Avoiding 'master' nomenclature
Date: Tue, 11 Aug 2020 17:30:40 -0700
Message-ID: <xmqq4kp8903z.fsf@gitster.c.googlers.com> (raw)
In-Reply-To: <nycvar.QRO.7.76.6.2008110430080.50@tvgsbejvaqbjf.bet> (Johannes Schindelin's message of "Tue, 11 Aug 2020 04:39:57 +0200 (CEST)")

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> However, this might be overkill, and a bit more complicated to implement,
> as we now would also have to allow "negative" patterns.

Somebody may want to teach negative patterns to merge.suppressDest,
so the implementation complexity in the end would not be all that
different in the end, when that future happens.  But until then, I
tend to agree with you that it may be simpler if the matched ones
are suppressed than mentioned (iow, the configuration variable,
merge.suppressDest, would be simpler to manage than your
hypothetical merge.mentionDest whose polarity is opposite).

That is primarily because I expect that the common usage patterns
are the following three:

 - mention destination of merges into any and all branches;

 - mention destination of no merges;

 - mention destination of merges into all branches except for the
   primary integration branch.

A configuration variable with either polarity would express the
first two equally well, but the last one (which is the primary use
case for continuity reasons) is easier to express with suppressDest.

With mentionDest, you'd need two entries, i.e. 'all', and 'not this
one', so you'd need a negative matching from the get-go.  So from
the point of view of end-user usability, not ease-of-implementation,
I think Peff picked the right polarity in his suggestion.

  reply index

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-29 19:44 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
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 [this message]
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=xmqq4kp8903z.fsf@gitster.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.net \
    --cc=torvalds@linux-foundation.org \
    /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