{"thread":{"id":"32030","subject":"Rebasing published branches?","startedAt":"2012-11-06T20:18:22Z","lastAt":"2012-11-06T23:14:51Z","messageCount":3,"participants":["Josef Wolf","Andrew Ardill","Antony Male"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"202597","messageId":"20121106201822.GE28437@raven.wolf.lan","threadId":"32030","inReplyTo":null,"subject":"Rebasing published branches?","fromName":"Josef Wolf","fromEmail":"jw@raven.inka.de","sentAt":"2012-11-06T20:18:22Z","receivedAt":"2012-11-06T20:18:22Z","isPatch":false,"sender":{"key":"jw@raven.inka.de","avatar":null},"body":"Hello,\n\nI know, I should never rebase published branches. But...\n\nI frequently work on different computers and would like to share my private\nbranches across them. When done and the feature is in a good shape, I'd like\nto rebase to clean up history before I make it available to other people.\n\nI guess rebasing such branches would be OK as long as I can reliably remember\nto delete those branches on _all_ the clones I ever created.\n\nBut waht if I ever make a mistake? How would one recover from such rebase\ndisasters? Anybody knows a good description how such a recover would be done?\n"},{"id":"202606","messageId":"CAH5451=ur1GGS7H+U9Tk-2-smrEd7xbJsL2hQibO8JBeFGNiUg@mail.gmail.com","threadId":"32030","inReplyTo":"20121106201822.GE28437@raven.wolf.lan","subject":"Re: Rebasing published branches?","fromName":"Andrew Ardill","fromEmail":"andrew.ardill@gmail.com","sentAt":"2012-11-06T22:53:00Z","receivedAt":"2012-11-06T22:53:00Z","isPatch":false,"sender":{"key":"andrew.ardill@gmail.com","avatar":"https://gravatar.com/avatar/da14cb7c091dd44dc6c63a4d3361b149acaf25226dc78eb4131a17b93d9b0993?d=mp&s=160"},"body":"Hi Josef,\n\nOn 7 November 2012 07:18, Josef Wolf <jw@raven.inka.de> wrote:\n>\n> Hello,\n>\n> I know, I should never rebase published branches. But...\n>\n> I frequently work on different computers and would like to share my private\n> branches across them. When done and the feature is in a good shape, I'd like\n> to rebase to clean up history before I make it available to other people.\n>\n> I guess rebasing such branches would be OK as long as I can reliably remember\n> to delete those branches on _all_ the clones I ever created.\n>\n> But waht if I ever make a mistake? How would one recover from such rebase\n> disasters? Anybody knows a good description how such a recover would be done?\n\n\nThe only real problem you should encounter is not knowing which\nrepository holds the 'true' feature branch, that is the one which you\nwant to publish.\n\nThe reason why rebasing public branches (where 'public' means somebody\n_else_ is tracking your branch) is bad is that you are rewriting\nsomebody else's history. This can cause headache and pain for them if\nthey have based work off what you have already published.\n\nIn your situation, you are the only one working on these feature\nbranches, and you know that you plan to rebase them. There is little\nrisk of you rewriting someone else's history, and even if you did it\nis clear that these branches were always meant to be rebased so you\nshould surprise anyone.\n\nAs a practical note, you'll probably find it easier to keep track of\nthe current state of your feature if you use one repository as your\nown 'blessed' repository. After working on a clone somewhere, always\npush to the blessed repository, and sync from it before you start\nwork. This way you will always have the correct version of your\nfeature branch.\n\nIf worse comes to worse (somehow) remember that rebasing does not\ndelete the old commits, just recreates them and points the branch at\nthe recreated versions. The old versions of these commits should be\navailable in the reflog, at least for a few weeks after the rebase.\n\nRegards,\n\nAndrew Ardill\n"},{"id":"202607","messageId":"509999EB.5050407@gmail.com","threadId":"32030","inReplyTo":"20121106201822.GE28437@raven.wolf.lan","subject":"Re: Rebasing published branches?","fromName":"Antony Male","fromEmail":"antony.male@gmail.com","sentAt":"2012-11-06T23:14:51Z","receivedAt":"2012-11-06T23:14:51Z","isPatch":false,"sender":{"key":"antony.male@gmail.com","avatar":"https://gravatar.com/avatar/44ebc98c2d05837be689ed72514f8119844424a9cf099e5202be4190281982f1?d=mp&s=160"},"body":"On 06/11/2012 8:18 pm, Josef Wolf wrote:\n> Hello,\n>\n> I know, I should never rebase published branches. But...\n\n\nThe major trouble with making rewritten branches public is one of merges.\n\nAssume I have two local repos, A and B, sharing a single remote. I \ncreate a branch in A, push it to the remote, then fetch it into B. I \nthen re-write the branch in A and force-push it, and fetch from B.\n\nAs far as B is now concerned, its local history diverges from the \nremote's -- a scenario which must be resolved, usually through a merge, \nbefore any work can be pushed. Unfortunately, this merge merges together \nthe two versions of history -- the old one from B's local history, and \nthe new one from the remote -- leading to a mess. If B then pushes, this \nmess is published.\n\nSo \"published\", in the \"don't rewrite published branches\" sense, means \n\"a branch which someone else might regularly pull from, and in doing so \nmerge together two versions of history\".\n\nIn general, remembering that you've pushed rewritten history, and to \nmakes sure that you haven't merged two versions of history after a \nmerge/pull, is sufficient. After rewriting history on a remote, rebase / \npull --rebase on a local, un-rewritten branch is sufficient to avoid the \nmerging-two-versions-of-history nightmare.\n\nSee \"RECOVERING FROM UPSTREAM REBASE\" in man git-rebase for a more \nin-depth explanation and more discussion of solutions.\n\n> I frequently work on different computers and would like to share my private\n> branches across them. When done and the feature is in a good shape, I'd like\n> to rebase to clean up history before I make it available to other people.\n\nRebasing a branch which is about to be deleted (after merging, \npresumably) is generally regarded as fine, provided you're not expecting \npeople to base work on the branch before it's rewritten.\n\nAntony\n"}]}