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

From: Jeff King <peff@peff.net>
Date: Aug 3, 2020, 21:11 UTC
Message-ID: <20200803211112.GA2720049@coredump.intra.peff.net>
In-Reply-To: <xmqq1rknv3xl.fsf@gitster.c.googlers.com>

On Mon, Aug 03, 2020 at 02:02:14PM -0700, Junio C Hamano wrote:

Show 17 quoted lines

> > There are probably some rough edges that could be smoothed (only looking
> > in refs/heads/ and using branch names instead of fully qualified refs,
> > handling the case that $to already exists more gracefully, better
> > prompting). But something like that might be useful for projects that
> > are transitioning.
> >
> > Note that it only works with protocol v2, though, because we don't
> > report non-HEAD symrefs in v0.
> 
> Renaming local branches themselves is probably the least interesting
> part.  You could even do _without_ renaming your local branches at
> all and keep working without any problem.  But you need to be able
> to adjust to the renaming upstream does, so if your 'topic' branch
> builds on top of 'refs/remotes/origin/master' and your upstream
> renames it to 'refs/remotes/origin/stuff' you'd need to reconfigure
> 'topic' branch to also build on and/or integrate with 'stuff'
> instead of 'master'.

Yeah, good point. That would be pretty easy to add to the script I showed by looking at:

  git config --get-regexp 'branch\..*\.merge' refs/heads/master

And I guess checking the matching branch.*.remote to match $remote. I think we're getting to the realm where it would be easier to implement in something besides shell. :)

But I do think a "branch renaming" helper like this might be useful for projects undergoing this rename. I don't think it makes sense to have as a first-class Git command, but I wouldn't be opposed to carrying something like it in contrib/ if somebody wanted to polish it up.

-Peff