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

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

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.

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

Jeff King <peff@peff.net> writes:

Yup, don't have real ssh access.

Hmmm, there's no way to update the hooks without shell access, right...?

[lots of stuff seems undoable without shell access, i.e., changing .git/descriptions; it'd be nice if there was at least some way to frob all this stuff ...]

-Miles

On Thu, Apr 16, 2009 at 05:00:39PM +0900, Miles Bader wrote:

No, not through any means shipped with git itself. There are obvious security implications to arbitrarily modifying hooks, since they are runnable code. In other words, updating hooks is a great way to _get_ shell access. :)

There is no reason to forbid enabling hooks which have been pre-approved by the site admin, but such a policy decision is outside the scope of git itself. The only mechanism git provides is the "templates" feature of init (so that a site admin can apply the same hook setup to all repos as they are created).

In general, git takes the approach that users can edit files in .git/ directly, and for setups where they can't, it is up to the site admin to make wrappers implementing whatever policy they want. Third party tools can provide the mechanism for accomplishing that (I don't know what support something like gitosis has for enabling hooks, updating descriptions, or moving branches, though).

-Peff

On Thu, Apr 16, 2009 at 2:59 AM, Jeff King <peff@peff.net> 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?

j.

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

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

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

Jeff King <peff@peff.net> writes:

The use-case which prompted my question was "retiring" obsolete branches that exist on a public server (which is usually only interactived with remotely using git).

E.g., a project has a long-term public branch "oink" which is finally merged to master, and thereafter ceases to be kept up-to-date. Sometimes the developers are reluctant to delete it becaue they want to keep the history around. However simply leaving it in place can be pretty confusing, as people tend to keep downloading it, not realizing how out-of-date it is. A nice compromise is to rename "oink" to "obsolete/oink", which keeps around the history for easy perusal, but makes the status of the branch pretty clear at a glance.

-Miles

On Fri, Apr 17, 2009 at 09:51:36AM +0900, Miles Bader wrote:

For some definition of "history", I suppose. Everything of interest should now be part of the history of "master", except:

  1.  you can no longer refer to the branch by name (but why would you
      want to, if it is now obsolete?)

  2. the reflog history for oink would be gone (but that will be gone
     anyway after the 90-day expiration period)

So I think it is a case of those developers being overly cautious. But I respect the fact that it is sometimes easier to simply move the branches than try to convince them otherwise.

If you were keeping reflogs forever for auditing purposes (as has been discussed elsewhere in the thread about gentoo), then I can see some point to (2). But in such a workflow, your "delete and create" strategy doesn't help at all, as the reflog is still purged. You would want to disable branch deletion entirely in such a workflow, and use a first-class move command. So a first-class "move remote branch" operation would be useful there.

-Peff

On Thu, Apr 16, 2009 at 5:09 PM, Jay Soffian <jaysoffian@gmail.com> wrote:

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