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

[Jeff King <peff@peff.net>]

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

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