{"thread":{"id":"30155","subject":"Linear history *and* share a branch?","startedAt":"2012-04-05T20:48:23Z","lastAt":"2012-04-10T23:54:54Z","messageCount":7,"participants":["Hilco Wijbenga","Ævar Arnfjörð Bjarmason","Junio C Hamano","Michael Witten","Neal Kreitzinger"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"188592","messageId":"CAE1pOi0-uSaQwgJHMTkw3nqp=idxZxMbyfKtLni0=Xwu-L-_hA@mail.gmail.com","threadId":"30155","inReplyTo":null,"subject":"Linear history *and* share a branch?","fromName":"Hilco Wijbenga","fromEmail":"hilco.wijbenga@gmail.com","sentAt":"2012-04-05T20:48:23Z","receivedAt":"2012-04-05T20:48:23Z","isPatch":false,"sender":{"key":"hilco.wijbenga@gmail.com","avatar":null},"body":"Hi all,\n\nWe have been using Git for about a year now in a very small team. So\nfar, everyone has worked on their own local branches and been doing\n\"git rebase master\" to make sure their local branches stay in synch.\nThis way we have a nice linear history in master.\n\nRecently, it has become useful to share one of these local branches\nbetween two devs. Of course, when one of the devs does his usual \"git\nrebase master\", he screws up the other dev's environment. Our solution\nhas been to keep rebasing the shared branch but to actually work on a\nlocal branch that is rebased on the shared branch. By judiciously\nusing \"git reset\" and \"git pull\" on the shared branch the two devs can\nkeep the shared branch in synch and then use \"git rebase\nshared-branch\" on their local branch to keep it in synch to. While\nthis works, there is probably a better/simpler solution.\n\nShould we simply do \"git merge master\" instead of \"git rebase master\"?\nAnd then do something at the end when we are about to merge the shared\nbranch back into master to guarantee linear history? Your thoughts and\nideas would be greatly appreciated.\n\nCheers,\nHilco\n"},{"id":"188593","messageId":"CACBZZX6za0+MXi4nPiV5ZuCKa91cPz0aye6FZG4gGAdqj0GqcA@mail.gmail.com","threadId":"30155","inReplyTo":"CAE1pOi0-uSaQwgJHMTkw3nqp=idxZxMbyfKtLni0=Xwu-L-_hA@mail.gmail.com","subject":"Re: Linear history *and* share a branch?","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2012-04-05T20:56:39Z","receivedAt":"2012-04-05T20:56:39Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Thu, Apr 5, 2012 at 22:48, Hilco Wijbenga wrote:\n> Should we simply do \"git merge master\" instead of \"git rebase master\"?\n> And then do something at the end when we are about to merge the shared\n> branch back into master to guarantee linear history? Your thoughts and\n> ideas would be greatly appreciated.\n\nYes, that's the most sensible workflow to have. You create a topic\nbranch, push/pull it back and forth, do merge commits and never rebase\nit, then when you decide if it's finished you can either merge it into\nthe mainline (with non-linear history), or have someone rebase it and\npush it to the mainline.\n\nI use the latter workflow extensively in my work e.g. when peer\nprogramming. We'll both have the same branch set up as a tracking\nbranch, make a bunch of WIP commits with crappy commit messages for a\nday or so, then at the end of the day interactively rebase the branch,\nand push it with linear history to the mainline.\n"},{"id":"188595","messageId":"7vfwch51nn.fsf@alter.siamese.dyndns.org","threadId":"30155","inReplyTo":"CAE1pOi0-uSaQwgJHMTkw3nqp=idxZxMbyfKtLni0=Xwu-L-_hA@mail.gmail.com","subject":"Re: Linear history *and* share a branch?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-04-05T21:06:36Z","receivedAt":"2012-04-05T21:06:36Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Hilco Wijbenga writes:\n\n> Hi all,\n>\n> We have been using Git for about a year now in a very small team. So\n> far, everyone has worked on their own local branches and been doing\n> \"git rebase master\" to make sure their local branches stay in synch.\n> This way we have a nice linear history in master.\n>\n> Recently, it has become useful to share one of these local branches\n> between two devs. Of course, when one of the devs does his usual \"git\n> rebase master\", he screws up the other dev's environment. Our solution\n> has been to keep rebasing the shared branch but to actually work on a\n> local branch that is rebased on the shared branch. By judiciously\n> using \"git reset\" and \"git pull\" on the shared branch the two devs can\n> keep the shared branch in synch and then use \"git rebase\n> shared-branch\" on their local branch to keep it in synch to. While\n> this works, there is probably a better/simpler solution.\n>\n> Should we simply do \"git merge master\" instead of \"git rebase master\"?\n\nThat certainly is a sensible thing to do.\n\nBut if your people are used to rebasing their own 'master' on top of\nshared 'master', I would imagine that it wouldn't be hard at all for these\ntwo people that work on a topic branch to do the same for their 'topic'\nbranch, no? Just like rebasing their 'master' on shared 'master', they\nwould rebase their own 'topic' on shared 'topic'.\n"},{"id":"188599","messageId":"CAE1pOi3Xmv-P4FN-eDkauT2becvdj9rVyFh-hEmVKnnB_pu2ug@mail.gmail.com","threadId":"30155","inReplyTo":"7vfwch51nn.fsf@alter.siamese.dyndns.org","subject":"Re: Linear history *and* share a branch?","fromName":"Hilco Wijbenga","fromEmail":"hilco.wijbenga@gmail.com","sentAt":"2012-04-05T21:57:36Z","receivedAt":"2012-04-05T21:57:36Z","isPatch":false,"sender":{"key":"hilco.wijbenga@gmail.com","avatar":null},"body":"On 5 April 2012 14:06, Junio C Hamano wrote:\n> Hilco Wijbenga writes:\n>> Hi all,\n>>\n>> We have been using Git for about a year now in a very small team. So\n>> far, everyone has worked on their own local branches and been doing\n>> \"git rebase master\" to make sure their local branches stay in synch.\n>> This way we have a nice linear history in master.\n>>\n>> Recently, it has become useful to share one of these local branches\n>> between two devs. Of course, when one of the devs does his usual \"git\n>> rebase master\", he screws up the other dev's environment. Our solution\n>> has been to keep rebasing the shared branch but to actually work on a\n>> local branch that is rebased on the shared branch. By judiciously\n>> using \"git reset\" and \"git pull\" on the shared branch the two devs can\n>> keep the shared branch in synch and then use \"git rebase\n>> shared-branch\" on their local branch to keep it in synch to. While\n>> this works, there is probably a better/simpler solution.\n>>\n>> Should we simply do \"git merge master\" instead of \"git rebase master\"?\n>\n> That certainly is a sensible thing to do.\n>\n> But if your people are used to rebasing their own 'master' on top of\n> shared 'master', I would imagine that it wouldn't be hard at all for these\n> two people that work on a topic branch to do the same for their 'topic'\n> branch, no?  Just like rebasing their 'master' on shared 'master', they\n> would rebase their own 'topic' on shared 'topic'.\n\nI'm not sure I'm following you here. I agree with what you say but I'm\nnot clear on exactly how it applies to what I asked. :-/\n\nRebasing the 'local-topic' on 'shared-topic' branch is certainly\npossible but that would not help with linear history with regards to\n'master', right? And rebasing 'shared-topic' on 'master' (to get its\nupdates) would \"break\" one of the dev's environments. Unless you mean\nthey should both do that separately? I suppose that's possible. I'm\nnot clear on the consequences.\n\nIt seems that (as Aevar said) we should simply ignore linear history\nwhile 'shared-topic' exists and only rebase on master when integrating\nit back into master. But I get the impression that you might have a\nslightly different approach in mind?\n"},{"id":"188622","messageId":"c9ba22f806704f8689544d29455a242f-mfwitten@gmail.com","threadId":"30155","inReplyTo":"CAE1pOi0-uSaQwgJHMTkw3nqp=idxZxMbyfKtLni0=Xwu-L-_hA@mail.gmail.com","subject":"Re: Linear history *and* share a branch?","fromName":"Michael Witten","fromEmail":"mfwitten@gmail.com","sentAt":null,"receivedAt":"2012-04-06T02:32:23Z","isPatch":false,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"On Thu, 5 Apr 2012 13:48:23 -0700, Hilco Wijbenga wrote:\n\n> We have been using Git for about a year now in a very small team. So\n> far, everyone has worked on their own local branches and been doing\n> \"git rebase master\" to make sure their local branches stay in synch.\n> This way we have a nice linear history in master.\n>\n> Recently, it has become useful to share one of these local branches\n> between two devs. Of course, when one of the devs does his usual \"git\n> rebase master\", he screws up the other dev's environment. Our solution\n> has been to keep rebasing the shared branch but to actually work on a\n> local branch that is rebased on the shared branch. By judiciously\n> using \"git reset\" and \"git pull\" on the shared branch the two devs can\n> keep the shared branch in synch and then use \"git rebase\n> shared-branch\" on their local branch to keep it in synch to. While\n> this works, there is probably a better/simpler solution.\n\nI think you can keep doing what you're doing, but simplify the\nmanagement. I try to express this more precisely below.\n\nTake all this with a grain of salt; it's kind of off the top of\nmy head, untested, and probably wrong (all the more so, because\nit has been a while since I had to think about these commands\nor workflows). Sorry if this is no different than what you're\nalready doing.\n\nFor a branch head `X' and a branch head `Y', let:\n\n X > Y\n\nmean that X should be periodically rebased on Y.\n\nYour team could have the following repository (that is,\nthere is a branch head `shared' and a branch head `master',\nand `shared' should be periodically rebased on `master'):\n\n origin:\n shared > master\n\nDeveloper `A' has a repository with a remote-tracking\nbranch `origin/shared', and a topic branch `local':\n\n A:\n local > origin/shared\n\nSimilarly for Developer `B':\n\n B:\n local > origin/shared\n\nThe concerns are separated as follows (I'm being a\nlittle more explicit with the commands than what is\nprobably necessary):\n\n origin:\n git rebase master shared\n\n A and B:\n git checkout local\n # do some work with `local'\n # ...\n git pull --rebase origin +shared:remotes/origin/shared\n git push origin local:shared # If this fails, do the pull again.\n\nIn actuality, the `origin' maintenance can be done by Developer `A'\nor `B', too; from one of their repositories:\n\n git fetch origin +master:remotes/origin/master \\\n +shared:remotes/origin/shared\n git checkout -b shared origin/shared\n git rebase origin/master shared\n git push origin +shared:shared\n git checkout local\n git branch -D shared\n\nWith a suitably set up configuration, you could probably automate a lot\nof the command line arguments. For instance, if the `A' and `B' repos\nhave configurations that look something like the following:\n\n [remote \"origin\"]\n fetch = +refs/heads/*:refs/remotes/origin/*\n ...\n\n [push]\n default = upstream\n\n [branch \"local\"]\n remote = origin\n merge = shared\n rebase = true\n\nthen the usual `A' and `B' workflow could simply be:\n\n git checkout local\n # do some work with `local'\n # ...\n git pull\n git push # If this fails, do the pull again.\n\nand as for rebasing `shared' in `origin', at least the fetch would just\nbecome just `git fetch'.\n\n... I think...\n\nSincerely,\nMichael Witten\n"},{"id":"188647","messageId":"CACBZZX7+cp6CwsnWmc8P1i9SabiTOJZXO9w-3E_m1A83gZKA6w@mail.gmail.com","threadId":"30155","inReplyTo":"CACBZZX6za0+MXi4nPiV5ZuCKa91cPz0aye6FZG4gGAdqj0GqcA@mail.gmail.com","subject":"Re: Linear history *and* share a branch?","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2012-04-06T10:04:21Z","receivedAt":"2012-04-06T10:04:21Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Thu, Apr 5, 2012 at 22:56, Ævar Arnfjörð Bjarmason wrote:\n> On Thu, Apr 5, 2012 at 22:48, Hilco Wijbenga wrote:\n>> Should we simply do \"git merge master\" instead of \"git rebase master\"?\n>> And then do something at the end when we are about to merge the shared\n>> branch back into master to guarantee linear history? Your thoughts and\n>> ideas would be greatly appreciated.\n>\n> Yes, that's the most sensible workflow to have. You create a topic\n> branch, push/pull it back and forth, do merge commits and never rebase\n> it, then when you decide if it's finished you can either merge it into\n> the mainline (with non-linear history), or have someone rebase it and\n> push it to the mainline.\n>\n> I use the latter workflow extensively in my work e.g. when peer\n> programming. We'll both have the same branch set up as a tracking\n> branch, make a bunch of WIP commits with crappy commit messages for a\n> day or so, then at the end of the day interactively rebase the branch,\n> and push it with linear history to the mainline.\n\nTo elaborate, this is how to do the workflow I'm talking about, with a\ngit set to push.default=tracking.\n\nThe person setting up the topic branch does this, \"origin\" is our\nshared upstream server. This creates a new topic and pushes it:\n\n git checkout -b team-whatever/some-topic\n git push origin -u team-whatever/some-topic\n\nEveryone else does this:\n\n git fetch origin\n git checkout -t team-whatever/some-topic\n\nThen everyone hacks, and does a \"git pull --no-rebase && git push\" to\npush work. When you're pair programming and switching between\ncomputers this'll often be:\n\n git commit -a -m\"wip\"\n git push\n\nFollowed by, on the other box:\n\n git pull --no-rebase\n\nThen when the topic is ready and you want to push it to the mainline\nsomeone does:\n\n git fetch origin\n git rebase -i origin/master\n\nand rewords/squashes/fixes up the various commits, followed by:\n\n # Now fixed up, push to the mainline\n git push origin team-whatever/some-topic:master\n # Nuke the now-redundant topic branch\n git push origin --delete team-whatever/some-topic\n"},{"id":"188918","messageId":"4F84C84E.1060602@gmail.com","threadId":"30155","inReplyTo":"CAE1pOi0-uSaQwgJHMTkw3nqp=idxZxMbyfKtLni0=Xwu-L-_hA@mail.gmail.com","subject":"Re: Linear history *and* share a branch?","fromName":"Neal Kreitzinger","fromEmail":"nkreitzinger@gmail.com","sentAt":"2012-04-10T23:54:54Z","receivedAt":"2012-04-10T23:54:54Z","isPatch":false,"sender":{"key":"nkreitzinger@gmail.com","avatar":null},"body":"On 4/5/2012 3:48 PM, Hilco Wijbenga wrote:\n> Hi all,\n>\n> We have been using Git for about a year now in a very small team. So\n> far, everyone has worked on their own local branches and been doing\n> \"git rebase master\" to make sure their local branches stay in synch.\n> This way we have a nice linear history in master.\n>\n> Recently, it has become useful to share one of these local branches\n> between two devs. Of course, when one of the devs does his usual\n> \"git rebase master\", he screws up the other dev's environment. Our\n> solution has been to keep rebasing the shared branch but to actually\n> work on a local branch that is rebased on the shared branch. By\n> judiciously using \"git reset\" and \"git pull\" on the shared branch the\n> two devs can keep the shared branch in synch and then use \"git\n> rebase shared-branch\" on their local branch to keep it in synch to.\n> While this works, there is probably a better/simpler solution.\n>\n> Should we simply do \"git merge master\" instead of \"git rebase\n> master\"? And then do something at the end when we are about to merge\n> the shared branch back into master to guarantee linear history? Your\n> thoughts and ideas would be greatly appreciated.\n>\nI haven't tried this, but at the point when your topic branch is ready \nfor master and the only thing left to do is make the history linear \nbefore publishing it you could: rebuild the branch using cherry pick. \nYou could cherry pick only the merge-commits over and that would drop \nall the merge history. You would end up with linear history. Then you \ncould further cleanup that linear history with rebase -i before you \npublish it.\n\nI haven't tried cherry picking a merge commit so I'm assuming it only \nbrings over the commit content and not the merge history.\n\nv/r,\nneal\n"}]}