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

[Junio C Hamano <gitster@pobox.com>]

Jeff King <peff@peff.net> writes:

> Something like this script could be run on the clients:
>
>   remote=origin
>   git ls-remote --symref $remote |
>   grep ^ref: |
>   while read junk to from; do
>     if test "$from" = HEAD; then
>       old=$(git symbolic-ref refs/remotes/$remote/HEAD)
>       echo "Upstream switched their HEAD:"
>       echo "  old: $old"
>       echo "  new: $to"
>       echo "Update to match?"
>       read r </dev/tty
>       if test "$r" = yes; then
>         git symbolic-ref refs/remotes/$remote/HEAD $to
>       fi
>     else
>       # do we even have the old branch?
>       git rev-parse --verify $from >/dev/null 2>&1 || continue
>       echo "Upstream is redirecting a branch:"
>       echo "     branch: $from"
>       echo "  points to: $to"
>       echo "And you have a local $from; should we rename it?"
>       read r </dev/tty
>       if test "$r" = yes; then
>         git branch -m ${from#refs/heads/} ${to#refs/heads/}
>       fi
>     fi
>   done
>
> 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'.