{"thread":{"id":"18891","subject":"renaming remote branches","startedAt":"2009-04-16T03:27:31Z","lastAt":"2009-04-17T16:20:52Z","messageCount":9,"participants":["Miles Bader","Jeff King","Jay Soffian","Dmitry Potapov"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"111413","messageId":"buo3ac9jn18.fsf@dhlpc061.dev.necel.com","threadId":"18891","inReplyTo":null,"subject":"renaming remote branches","fromName":"Miles Bader","fromEmail":"miles.bader@necel.com","sentAt":"2009-04-16T03:27:31Z","receivedAt":"2009-04-16T03:27:31Z","isPatch":false,"sender":{"key":"miles.bader@necel.com","avatar":"https://gravatar.com/avatar/be062d4050eb88e04229cbdb60f803e1bd647923a015996c2439e76f23e336a7?d=mp&s=160"},"body":"I can \"rename\" a remote branch by doing:\n\n git push REMOTE REMOTE/OLD:refs/heads/NEW\n git push REMOTE :OLD\n\nis there any better way to do this (I mean, er... more\nuser-friendly/less-dangerous/... I dunno... \"better\" :-)?\n\nAlso, I note that the old name (\"OLD\") remains in .git/info/refs, both\nlocally and in the remote; is this a problem? I can update the local\n.git/info/refs by running \"git update-server-info\", but I'm not sure how\nto do in for the remote repo without having a login there...\n\nThanks,\n\n-miles\n\n-- \nErudition, n. Dust shaken out of a book into an empty skull.\n"},{"id":"111423","messageId":"20090416065934.GA20071@coredump.intra.peff.net","threadId":"18891","inReplyTo":"buo3ac9jn18.fsf@dhlpc061.dev.necel.com","subject":"Re: renaming remote branches","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-04-16T06:59:34Z","receivedAt":"2009-04-16T06:59:34Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Apr 16, 2009 at 12:27:31PM +0900, Miles Bader wrote:\n\n> I can \"rename\" a remote branch by doing:\n> \n> git push REMOTE REMOTE/OLD:refs/heads/NEW\n> git push REMOTE :OLD\n> \n> is there any better way to do this (I mean, er... more\n> user-friendly/less-dangerous/... I dunno... \"better\" :-)?\n\nNo, the git protocol doesn't know about moving refs at all, so you are\nstuck with creation and deletion (and the creation, as you noticed, is\neven more painful because we don't guess that \"NEW\" is going to be a\nbranch, so you are stuck saying \"refs/heads/\").\n\nNot only is this not user-friendly, but it does not preserve any branch\nconfig or reflog at the remote (both things that \"branch -m\" does).\n\nIn your situation, I would probably do:\n\n ssh remote-host 'cd remote-dir && git branch -m OLD NEW'\n\nbut that is not always an option, depending on your setup.\n\n> Also, I note that the old name (\"OLD\") remains in .git/info/refs, both\n> locally and in the remote; is this a problem? I can update the local\n> .git/info/refs by running \"git update-server-info\", but I'm not sure how\n> to do in for the remote repo without having a login there...\n\nIf you are not sharing your repo over a dumb transport (like http), then\nthe contents of .git/info/refs shouldn't matter. If you are, then you\nshould enable the post-update hook to run update-server-info after every\npush (i.e., it is not just the deletion that is a problem, but none of\nyour pushes is being marked in .git/info/refs).\n\n-Peff\n"},{"id":"111429","messageId":"buoab6h2fko.fsf@dhlpc061.dev.necel.com","threadId":"18891","inReplyTo":"20090416065934.GA20071@coredump.intra.peff.net","subject":"Re: renaming remote branches","fromName":"Miles Bader","fromEmail":"miles@gnu.org","sentAt":"2009-04-16T08:00:39Z","receivedAt":"2009-04-16T08:00:39Z","isPatch":false,"sender":{"key":"miles@gnu.org","avatar":"https://gravatar.com/avatar/01069b69593af7bff28e2f97afeb3644ae6fe2f5f56cb3a8cf34c5fb8c36efe5?d=mp&s=160"},"body":"Jeff King writes:\n> In your situation, I would probably do:\n> ssh remote-host 'cd remote-dir && git branch -m OLD NEW'\n> but that is not always an option, depending on your setup.\n\nYup, don't have real ssh access.\n\n>> Also, I note that the old name (\"OLD\") remains in .git/info/refs, both\n>> locally and in the remote; is this a problem? I can update the local\n>> .git/info/refs by running \"git update-server-info\", but I'm not sure how\n>> to do in for the remote repo without having a login there...\n>\n> If you are not sharing your repo over a dumb transport (like http), then\n> the contents of .git/info/refs shouldn't matter. If you are, then you\n> should enable the post-update hook to run update-server-info after every\n> push (i.e., it is not just the deletion that is a problem, but none of\n> your pushes is being marked in .git/info/refs).\n\nHmmm, there's no way to update the hooks without shell access, right...?\n\n[lots of stuff seems undoable without shell access, i.e., changing\n.git/descriptions; it'd be nice if there was at least some way to frob\nall this stuff ...]\n\n-Miles\n\n-- \nAccordion, n. An instrument in harmony with the sentiments of an assassin.\n"},{"id":"111431","messageId":"20090416081835.GA26972@coredump.intra.peff.net","threadId":"18891","inReplyTo":"buoab6h2fko.fsf@dhlpc061.dev.necel.com","subject":"Re: renaming remote branches","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-04-16T08:18:35Z","receivedAt":"2009-04-16T08:18:35Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Apr 16, 2009 at 05:00:39PM +0900, Miles Bader wrote:\n\n> > If you are not sharing your repo over a dumb transport (like http), then\n> > the contents of .git/info/refs shouldn't matter. If you are, then you\n> > should enable the post-update hook to run update-server-info after every\n> > push (i.e., it is not just the deletion that is a problem, but none of\n> > your pushes is being marked in .git/info/refs).\n> \n> Hmmm, there's no way to update the hooks without shell access, right...?\n\nNo, not through any means shipped with git itself. There are obvious\nsecurity implications to arbitrarily modifying hooks, since they are\nrunnable code. In other words, updating hooks is a great way to _get_\nshell access. :)\n\nThere is no reason to forbid enabling hooks which have been pre-approved\nby the site admin, but such a policy decision is outside the scope of\ngit itself. The only mechanism git provides is the \"templates\" feature\nof init (so that a site admin can apply the same hook setup to all\nrepos as they are created).\n\n> [lots of stuff seems undoable without shell access, i.e., changing\n> .git/descriptions; it'd be nice if there was at least some way to frob\n> all this stuff ...]\n\nIn general, git takes the approach that users can edit files in .git/\ndirectly, and for setups where they can't, it is up to the site admin to\nmake wrappers implementing whatever policy they want. Third party tools\ncan provide the mechanism for accomplishing that (I don't know what\nsupport something like gitosis has for enabling hooks, updating\ndescriptions, or moving branches, though).\n\n-Peff\n"},{"id":"111445","messageId":"76718490904160609s1ef9c1e0m6f19ff169666fa3@mail.gmail.com","threadId":"18891","inReplyTo":"20090416065934.GA20071@coredump.intra.peff.net","subject":"Re: renaming remote branches","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2009-04-16T13:09:17Z","receivedAt":"2009-04-16T13:09:17Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Thu, Apr 16, 2009 at 2:59 AM, Jeff King wrote:\n> Not only is this not user-friendly, but it does not preserve any branch\n> config or reflog at the remote (both things that \"branch -m\" does).\n\nI wonder whether we should:\n\na) teach git remote a rename-branch sub-command\nb) add support on the remote side for properly preserving the config and reflog\n\nThoughts?\n\nj.\n"},{"id":"111448","messageId":"20090416135037.GA7770@coredump.intra.peff.net","threadId":"18891","inReplyTo":"76718490904160609s1ef9c1e0m6f19ff169666fa3@mail.gmail.com","subject":"Re: renaming remote branches","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-04-16T13:50:37Z","receivedAt":"2009-04-16T13:50:37Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Apr 16, 2009 at 09:09:17AM -0400, Jay Soffian wrote:\n\n> On Thu, Apr 16, 2009 at 2:59 AM, Jeff King wrote:\n> > Not only is this not user-friendly, but it does not preserve any branch\n> > config or reflog at the remote (both things that \"branch -m\" does).\n> \n> I wonder whether we should:\n> \n> a) teach git remote a rename-branch sub-command\n\nI think that is a reasonable place for such a helper command to go,\nwhether it is tightly integrated with git or not (IOW, even with nothing\nelse, it might still be useful to have a wrapper to parse the remote\nhostname and directory from the config, ssh in, and run \"git branch\n-m\").\n\n> b) add support on the remote side for properly preserving the config and reflog\n\nDo you mean over the git protocol? I don't see a real reason not to have\nit (since we allow deletion already, the user is not doing anything\nmore destructive than what we already do). But I think any proposal\nwould have to spell out how the protocol could accomodate this in a\nbackwards-compatible manner.\n\nI wonder if we could simply do \"rename detection\" on the list of pushed\nrefs, and save the config and reflog in that case. IOW, detect\n\n git push remote remote/foo:refs/heads/bar :refs/heads/foo\n\nI think there is fundamentally a race condition with the \"create new and\ndelete old\" approach, though, as nothing is guaranteeing that your \"new\"\nand the remote's \"old\" have the same thing in them. You might be\ndeleting somebody else's new commits, no \"--force\" required. So probably\nit is better to be able to explicitly specify a rename.\n\n\nAll of that is assuming that remote renames are common enough to really\ncare about. Personally, I've never actually done one.\n\n-Peff\n"},{"id":"111470","messageId":"buomyagf6g7.fsf@dhlpc061.dev.necel.com","threadId":"18891","inReplyTo":"20090416135037.GA7770@coredump.intra.peff.net","subject":"Re: renaming remote branches","fromName":"Miles Bader","fromEmail":"miles@gnu.org","sentAt":"2009-04-17T00:51:36Z","receivedAt":"2009-04-17T00:51:36Z","isPatch":false,"sender":{"key":"miles@gnu.org","avatar":"https://gravatar.com/avatar/01069b69593af7bff28e2f97afeb3644ae6fe2f5f56cb3a8cf34c5fb8c36efe5?d=mp&s=160"},"body":"Jeff King writes:\n> All of that is assuming that remote renames are common enough to really\n> care about. Personally, I've never actually done one.\n\nThe use-case which prompted my question was \"retiring\" obsolete branches\nthat exist on a public server (which is usually only interactived with\nremotely using git).\n\nE.g., a project has a long-term public branch \"oink\" which is finally\nmerged to master, and thereafter ceases to be kept up-to-date.\nSometimes the developers are reluctant to delete it becaue they want to\nkeep the history around. However simply leaving it in place can be\npretty confusing, as people tend to keep downloading it, not realizing\nhow out-of-date it is. A nice compromise is to rename \"oink\" to\n\"obsolete/oink\", which keeps around the history for easy perusal, but\nmakes the status of the branch pretty clear at a glance.\n\n-Miles\n\n-- \nYo mama's so fat when she gets on an elevator it HAS to go down.\n"},{"id":"111484","messageId":"20090417120741.GD29121@coredump.intra.peff.net","threadId":"18891","inReplyTo":"buomyagf6g7.fsf@dhlpc061.dev.necel.com","subject":"Re: renaming remote branches","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-04-17T12:07:41Z","receivedAt":"2009-04-17T12:07:41Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Apr 17, 2009 at 09:51:36AM +0900, Miles Bader wrote:\n\n> E.g., a project has a long-term public branch \"oink\" which is finally\n> merged to master, and thereafter ceases to be kept up-to-date.\n> Sometimes the developers are reluctant to delete it becaue they want to\n> keep the history around. However simply leaving it in place can be\n\nFor some definition of \"history\", I suppose. Everything of interest\nshould now be part of the history of \"master\", except:\n\n 1. you can no longer refer to the branch by name (but why would you\n want to, if it is now obsolete?)\n\n 2. the reflog history for oink would be gone (but that will be gone\n anyway after the 90-day expiration period)\n\nSo I think it is a case of those developers being overly cautious. But I\nrespect the fact that it is sometimes easier to simply move the branches\nthan try to convince them otherwise.\n\nIf you were keeping reflogs forever for auditing purposes (as has been\ndiscussed elsewhere in the thread about gentoo), then I can see some\npoint to (2). But in such a workflow, your \"delete and create\" strategy\ndoesn't help at all, as the reflog is still purged. You would want to\ndisable branch deletion entirely in such a workflow, and use a\nfirst-class move command. So a first-class \"move remote branch\"\noperation would be useful there.\n\n-Peff\n"},{"id":"111502","messageId":"37fcd2780904170920m5a0c6c24se345275b0944e59d@mail.gmail.com","threadId":"18891","inReplyTo":"76718490904160609s1ef9c1e0m6f19ff169666fa3@mail.gmail.com","subject":"Re: renaming remote branches","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2009-04-17T16:20:52Z","receivedAt":"2009-04-17T16:20:52Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Thu, Apr 16, 2009 at 5:09 PM, Jay Soffian wrote:\n>\n> I wonder whether we should:\n>\n> a) teach git remote a rename-branch sub-command\n> b) add support on the remote side for properly preserving the config and reflog\n>\n> Thoughts?\n\nBesides a race condition in creating new and deleting old branch, which\nJeff already mentioned, it could be some other problems. For instance,\nhow this new feature is going to interact with the update hook that many\nusers already have? It seems to me there is no way to make it backward\ncompatible with existing update hooks, so it will require to add a new\nhook, and by default (unless this rename hook is explicitly allowed),\nrenaming should not be allowed, otherwise it can be used to circumvent\nrestrictions built inside 'update' hook.\n\nDmitry\n"}]}