Git Mailing List Archive on lore.kernel.org
 help / color / Atom feed
From: Jeff King <peff@peff.net>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Junio C Hamano <gitster@pobox.com>,
	Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	Git List Mailing <git@vger.kernel.org>
Subject: Re: Avoiding 'master' nomenclature
Date: Wed, 29 Jul 2020 20:29:44 -0400
Message-ID: <20200730002944.GB2996059@coredump.intra.peff.net> (raw)
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:

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

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

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

  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 [this message]
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
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=20200730002944.GB2996059@coredump.intra.peff.net \
    --to=peff@peff.net \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --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