list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Matt McCutchen <>
To: Junio C Hamano <>
Subject: Re: Renaming the "master" branch without breaking existing clones
Date: Mon, 03 Aug 2020 13:41:40 -0400	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Mon, 2020-08-03 at 09:14 -0700, Junio C Hamano wrote:
> Matt McCutchen <> writes:
> > 3. Ensuring that tools detect the default branch of a given repository
> > in an appropriate way rather than assuming "master".  Where applicable,
> > the remote HEAD symref is probably the best thing to use.
> I wonder if that would work well.  Your refs/remotes/origin/HEAD is
> designed to be tweaked by you to indicate which remote branch is of
> interest to you to your local Git.  Those who are interested in
> following along 'maint' can update refs/remotes/origin/HEAD to point
> at refs/remotes/origin/maint in their clone of this project, and
> they can say "git fetch origin && git log origin" to see the history
> leading to the tip of 'maint' in my repository.
> At least, that is how it is designed to work.  So "compare local
> refs/remotes/origin/HEAD and what 'git ls-remote origin' sees where
> they point at with their HEAD---if they are different, ours have old
> name and theirs have new name" is not a good heuristics.

Indeed.  I guess my proposal to use the HEAD symref of the remote
repository only applies to tools that interact with a central
repository and don't have a local repository that the user is allowed
to touch (there might be one for caching purposes only) and need to
know which branch to use if the user didn't specify one.  This would
include npm, yarn, etc., as mentioned in the article I linked.

If functionality is added to git to facilitate transitions for tools
that do have a local repository that the user is allowed to touch, as
you described, that would be great.


  reply	other threads:[~2020-08-03 17:41 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-03 12:15 Matt McCutchen
2020-08-03 16:00 ` Taylor Blau
2020-08-03 16:19   ` Junio C Hamano
2020-08-03 16:39     ` Taylor Blau
2020-08-03 19:40   ` Jeff King
2020-08-03 20:40     ` Junio C Hamano
2020-08-03 20:45     ` Jeff King
2020-08-03 21:02       ` Junio C Hamano
2020-08-03 21:11         ` Jeff King
2020-08-03 21:38           ` Junio C Hamano
2020-08-04  0:37     ` Matt McCutchen
2020-08-04  0:43   ` Matt McCutchen
2020-08-03 16:14 ` Junio C Hamano
2020-08-03 17:41   ` Matt McCutchen [this message]
2020-08-03 18:20   ` Kaartic Sivaraam
2020-08-03 18:47     ` Junio C Hamano
2020-08-04  8:50       ` Kaartic Sivaraam

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:

  List information:

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

  git send-email \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this inbox:

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).