git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Matt McCutchen <matt@mattmccutchen.net>
Cc: git@vger.kernel.org
Subject: Re: Renaming the "master" branch without breaking existing clones
Date: Mon, 03 Aug 2020 09:14:19 -0700	[thread overview]
Message-ID: <xmqqlfivwvtw.fsf@gitster.c.googlers.com> (raw)
In-Reply-To: <ec960483f5008e9948271c678d51876920ab62c9.camel@mattmccutchen.net> (Matt McCutchen's message of "Mon, 03 Aug 2020 08:15:58 -0400")

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.

If we wanted to do this properly, I'd imagine we'd need to add a
mechanism for repositories to convey "this branch that used to exist
got renamed to this other name", not specifically for any "special"
branch name (like 'master').  If we plan to never allow reusing the
old and banned name, it probably is enough to turn the old name into
a symbolic ref that points at the new name, e.g. in my repository

    $ git update-ref refs/heads/seen refs/heads/pu
    $ git update-ref -d refs/heads/pu
    $ git symbolic-ref refs/heads/pu refs/heads/seen

which would create a symbolic reference 'pu' that points at 'seen'
to say "pu used to exist but it is now seen".

But that would not work well, as we must allow reusing the old name,
as the primary point of renaming 'pu' to 'seen' in this project was
so that we can accept topics from contributors whose anglicized name
has 'p' and 'u' in capital letters as pu/$topicname branches.  Having
a symbolic ref 'pu' would defeat that plan.

So perhaps we'd need to emply the usual trick to have a blob on
"meta" ref, say "refs/meta/ref-rename" might contain multiple tuples
that tells the receiving end about each moved ref:

    - the name of the 'old' ref (e.g. 'refs/heads/pu')
    - the name of the 'new' ref (e.g. 'refs/heads/seen')
    - (optional) when the 'move' happened

As it does not make much sense to perform the local side migration
silently and behind the user's back while the user is actively
working in the repository, it is likely that the migration
instruction would be written as a "perform this when it is
convenient for you" one-time event.  It may start by fetching the
"meta/ref-rename" blob and perform "what to do when remote ref X is
moved to remote ref Y" procedure.

That procedure should also be executable offline, without the remote
end publishing the "meta/ref-rename" data.  If you know your upstream
has changed 'pu' to 'seen', you should be able to do

    $ git ref-migration-helper refs/remotes/origin/pu refs/remotes/origin/seen

so that many things related to these names are changed (and that is
the most complex part---compared to that, conveying what rename the
remote end did to the local Git is much simpler), including

    - renaming the remote-tracking branches (obvious)

    - reconfiguring local branches that have their upstream branch
      set to the 'old' remote-tracking branch to make their upstream
      branch to the 'new' remote-tracking branch.

There may be others.


  parent reply	other threads:[~2020-08-03 16:14 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 [this message]
2020-08-03 17:41   ` Matt McCutchen
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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=xmqqlfivwvtw.fsf@gitster.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=matt@mattmccutchen.net \
    /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
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:

	https://80x24.org/mirrors/git.git

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