renaming remote branches

I can "rename" a remote branch by doing:

   git push REMOTE REMOTE/OLD:refs/heads/NEW
   git push REMOTE :OLD

is there any better way to do this (I mean, er... more
user-friendly/less-dangerous/... I dunno... "better" :-)?

Also, I note that the old name ("OLD") remains in .git/info/refs, both
locally and in the remote; is this a problem?  I can update the local
.git/info/refs by running "git update-server-info", but I'm not sure how
to do in for the remote repo without having a login there...

Thanks,

-miles

-- 
Erudition, n. Dust shaken out of a book into an empty skull.

On Thu, Apr 16, 2009 at 12:27:31PM +0900, Miles Bader wrote:

I can "rename" a remote branch by doing:

   git push REMOTE REMOTE/OLD:refs/heads/NEW
   git push REMOTE :OLD

is there any better way to do this (I mean, er... more
user-friendly/less-dangerous/... I dunno... "better" :-)?

No, the git protocol doesn't know about moving refs at all, so you are
stuck with creation and deletion (and the creation, as you noticed, is
even more painful because we don't guess that "NEW" is going to be a
branch, so you are stuck saying "refs/heads/").

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

In your situation, I would probably do:

  ssh remote-host 'cd remote-dir && git branch -m OLD NEW'

but that is not always an option, depending on your setup.

Also, I note that the old name ("OLD") remains in .git/info/refs, both
locally and in the remote; is this a problem?  I can update the local
.git/info/refs by running "git update-server-info", but I'm not sure how
to do in for the remote repo without having a login there...

If you are not sharing your repo over a dumb transport (like http), then
the contents of .git/info/refs shouldn't matter. If you are, then you
should enable the post-update hook to run update-server-info after every
push (i.e., it is not just the deletion that is a problem, but none of
your pushes is being marked in .git/info/refs).

-Peff

On Thu, Apr 16, 2009 at 2:59 AM, Jeff King [off-list ref] 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
b) add support on the remote side for properly preserving the config and reflog

Thoughts?

j.

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

On Thu, Apr 16, 2009 at 2:59 AM, Jeff King [off-list ref] wrote:

quoted

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

On Thu, Apr 16, 2009 at 5:09 PM, Jay Soffian [off-list ref] wrote:

I wonder whether we should:

a) teach git remote a rename-branch sub-command
b) add support on the remote side for properly preserving the config and reflog

Thoughts?

Besides a race condition in creating new and deleting old branch, which
Jeff already mentioned, it could be some other problems. For instance,
how this new feature is going to interact with the update hook that many
users already have? It seems to me there is no way to make it backward
compatible with existing update hooks, so it will require to add a new
hook, and by default (unless this rename hook is explicitly allowed),
renaming should not be allowed, otherwise it can be used to circumvent
restrictions built inside 'update' hook.

Dmitry