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

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

Matt McCutchen [off-list ref] writes:

quoted

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