renaming remote branches

renaming remote branches

[Miles Bader]

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.

Re: renaming remote branches

[Jeff King]

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

Re: renaming remote branches

[Miles Bader]

Jeff King <peff@peff.net> writes:
> 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.

Yup, don't have real ssh access.

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

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

-- 
Accordion, n. An instrument in harmony with the sentiments of an assassin.

Re: renaming remote branches

[Jeff King]

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

> > 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).
> 
> Hmmm, there's no way to update the hooks without shell access, right...?

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

> [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 ...]

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

Re: renaming remote branches

[Jay Soffian]

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
b) add support on the remote side for properly preserving the config and reflog

Thoughts?

j.

Re: renaming remote branches

[Jeff King]

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

Re: renaming remote branches

[Miles Bader]

Jeff King <peff@peff.net> writes:
> All of that is assuming that remote renames are common enough to really
> care about. Personally, I've never actually done one.

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

-- 
Yo mama's so fat when she gets on an elevator it HAS to go down.

Re: renaming remote branches

[Jeff King]

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

> 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

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

Re: renaming remote branches

[Dmitry Potapov]

On Thu, Apr 16, 2009 at 5:09 PM, Jay Soffian <jaysoffian@gmail.com> 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