Re: Renaming the "master" branch without breaking existing clones

From: Matt McCutchen <matt@mattmccutchen.net>
Date: Aug 3, 2020, 17:41 UTC
Message-ID: <ce0283e1cb38dc84eb850e3cfc7b1a6225a60b42.camel@mattmccutchen.net>
In-Reply-To: <xmqqlfivwvtw.fsf@gitster.c.googlers.com>

On Mon, 2020-08-03 at 09:14 -0700, Junio C Hamano wrote:

Show 18 quoted lines

> Matt McCutchen <matt@mattmccutchen.net> 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.

Matt