Re: renaming remote branches

[Jeff King <peff@peff.net>]

On Thu, Apr 16, 2009 at 09:09:17AM -0400, Jay Soffian wrote:

> On Thu, Apr 16, 2009 at 2:59 AM, Jeff King <peff@peff.net> wrote:
> > Not only is this not user-friendly, but it does not preserve any branch
> > config or reflog at the remote (both things that "branch -m" does).
> 
> I wonder whether we should:
> 
> a) teach git remote a rename-branch sub-command

I think that is a reasonable place for such a helper command to go,
whether it is tightly integrated with git or not (IOW, even with nothing
else, it might still be useful to have a wrapper to parse the remote
hostname and directory from the config, ssh in, and run "git branch
-m").

> b) add support on the remote side for properly preserving the config and reflog

Do you mean over the git protocol? I don't see a real reason not to have
it (since we allow deletion already, the user is not doing anything
more destructive than what we already do). But I think any proposal
would have to spell out how the protocol could accomodate this in a
backwards-compatible manner.

I wonder if we could simply do "rename detection" on the list of pushed
refs, and save the config and reflog in that case. IOW, detect

  git push remote remote/foo:refs/heads/bar :refs/heads/foo

I think there is fundamentally a race condition with the "create new and
delete old" approach, though, as nothing is guaranteeing that your "new"
and the remote's "old" have the same thing in them. You might be
deleting somebody else's new commits, no "--force" required. So probably
it is better to be able to explicitly specify a rename.


All of that is assuming that remote renames are common enough to really
care about. Personally, I've never actually done one.

-Peff