{"thread":{"id":"6836","subject":"Dangers of working on a tracking branch","startedAt":"2007-02-15T20:49:09Z","lastAt":"2007-02-16T16:40:11Z","messageCount":22,"participants":["Bill Lear","Nicolas Pitre","Jeff King","Shawn O. Pearce","Jakub Narebski","Santi Béjar"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"34729","messageId":"17876.51013.561979.431717@lisa.zopyra.com","threadId":"6836","inReplyTo":null,"subject":"Dangers of working on a tracking branch","fromName":"Bill Lear","fromEmail":"rael@zopyra.com","sentAt":"2007-02-15T20:49:09Z","receivedAt":"2007-02-15T20:49:09Z","isPatch":false,"sender":{"key":"rael@zopyra.com","avatar":"https://gravatar.com/avatar/c4f2d2790ca3828d3b4e7dfebabf61d2fe94fd82fa49cdac2a5295dd2d46a874?d=mp&s=160"},"body":"We are about to switch to git 1.5 from git 1.4.4.1.  I cannot remember\nif someone posted about this, but what is the danger of working on a\ntracking branch --- there are abundant cautions about doing this, but\nI can't recall and can't find the reason this is bad.\n\n\nBill\n"},{"id":"34730","messageId":"Pine.LNX.4.64.0702151557410.1757@xanadu.home","threadId":"6836","inReplyTo":"17876.51013.561979.431717@lisa.zopyra.com","subject":"Re: Dangers of working on a tracking branch","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-02-15T21:00:23Z","receivedAt":"2007-02-15T21:00:23Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Thu, 15 Feb 2007, Bill Lear wrote:\n\n> We are about to switch to git 1.5 from git 1.4.4.1.  I cannot remember\n> if someone posted about this, but what is the danger of working on a\n> tracking branch --- there are abundant cautions about doing this, but\n> I can't recall and can't find the reason this is bad.\n\nA tracking branch is supposed to be a local mirror of what is available \nremotely.  If you commit local changes to it then you break that model.\n\nThis is why with Git 1.5.0 tracking branches are in a different \nnamespace by default to which you cannot commit.\n\n\nNicolas\n"},{"id":"34731","messageId":"17876.52962.662946.582507@lisa.zopyra.com","threadId":"6836","inReplyTo":"Pine.LNX.4.64.0702151557410.1757@xanadu.home","subject":"Re: Dangers of working on a tracking branch","fromName":"Bill Lear","fromEmail":"rael@zopyra.com","sentAt":"2007-02-15T21:21:38Z","receivedAt":"2007-02-15T21:21:38Z","isPatch":false,"sender":{"key":"rael@zopyra.com","avatar":"https://gravatar.com/avatar/c4f2d2790ca3828d3b4e7dfebabf61d2fe94fd82fa49cdac2a5295dd2d46a874?d=mp&s=160"},"body":"On Thursday, February 15, 2007 at 16:00:23 (-0500) Nicolas Pitre writes:\n>On Thu, 15 Feb 2007, Bill Lear wrote:\n>\n>> We are about to switch to git 1.5 from git 1.4.4.1.  I cannot remember\n>> if someone posted about this, but what is the danger of working on a\n>> tracking branch --- there are abundant cautions about doing this, but\n>> I can't recall and can't find the reason this is bad.\n>\n>A tracking branch is supposed to be a local mirror of what is available \n>remotely.  If you commit local changes to it then you break that model.\n\nOk, so I break the model, what is the harm in that?  Can I no longer\npull from or push to the remote branch?  Do I corrupt something\nlocally?  Does something else break?  I'm trying to formulate an\nexplanation to our users why the 1.5 way is superior and I can't just\nsay \"if you do that you break the model\".\n\n\nBill\n"},{"id":"34732","messageId":"17876.53654.426022.454712@lisa.zopyra.com","threadId":"6836","inReplyTo":"17876.52962.662946.582507@lisa.zopyra.com","subject":"Re: Dangers of working on a tracking branch","fromName":"Bill Lear","fromEmail":"rael@zopyra.com","sentAt":"2007-02-15T21:33:10Z","receivedAt":"2007-02-15T21:33:10Z","isPatch":false,"sender":{"key":"rael@zopyra.com","avatar":"https://gravatar.com/avatar/c4f2d2790ca3828d3b4e7dfebabf61d2fe94fd82fa49cdac2a5295dd2d46a874?d=mp&s=160"},"body":"On Thursday, February 15, 2007 at 15:21:38 (-0600) Bill Lear writes:\n>On Thursday, February 15, 2007 at 16:00:23 (-0500) Nicolas Pitre writes:\n>>On Thu, 15 Feb 2007, Bill Lear wrote:\n>>\n>>> We are about to switch to git 1.5 from git 1.4.4.1.  I cannot remember\n>>> if someone posted about this, but what is the danger of working on a\n>>> tracking branch --- there are abundant cautions about doing this, but\n>>> I can't recall and can't find the reason this is bad.\n>>\n>>A tracking branch is supposed to be a local mirror of what is available \n>>remotely.  If you commit local changes to it then you break that model.\n>\n>Ok, so I break the model, what is the harm in that?  Can I no longer\n>pull from or push to the remote branch?  Do I corrupt something\n>locally?  Does something else break?  I'm trying to formulate an\n>explanation to our users why the 1.5 way is superior and I can't just\n>say \"if you do that you break the model\".\n\nBTW, my ignorant assumption is that for merging to take place, git\nrequires two branches, so 'git pull' will fetch into the tracking\nbranch and then merge onto your ... uh ... whatever the name of the\nworking version of your tracking branch is.\n\nBTW, again, why does git clone not have an option to just create all\nof the \"working versions\" (better name needed) of tracking branches?\n\n\nBill\n"},{"id":"34733","messageId":"20070215214352.GA2980@coredump.intra.peff.net","threadId":"6836","inReplyTo":"17876.53654.426022.454712@lisa.zopyra.com","subject":"Re: Dangers of working on a tracking branch","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-02-15T21:43:52Z","receivedAt":"2007-02-15T21:43:52Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Feb 15, 2007 at 03:21:38PM -0600, Bill Lear wrote:\n\n> Ok, so I break the model, what is the harm in that?  Can I no longer\n> pull from or push to the remote branch?  Do I corrupt something\n> locally?  Does something else break?  I'm trying to formulate an\n> explanation to our users why the 1.5 way is superior and I can't just\n> say \"if you do that you break the model\".\n\nThe commits you make will not actually go onto that tracking branch;\nthey will be part of a \"detached HEAD\" (that is, your HEAD doesn't point\nto _any_ branch). Once you check out a different branch, you will\npotentially lose those commits (actually, they will still be available\nthrough your reflog, but you will have to know to look for them there).\n\n> BTW, my ignorant assumption is that for merging to take place, git\n> requires two branches, so 'git pull' will fetch into the tracking\n> branch and then merge onto your ... uh ... whatever the name of the\n> working version of your tracking branch is.\n\nThat's more or less correct. You don't really have to have two branches;\ndoing a 'git pull /path/to/repo branch' will fetch the branch into the\ntemporary FETCH_HEAD name, and merge from that. But yes, the way a raw\n'git pull' will work is to first fetch all tracking branches into\nrefs/remotes/origin/*, and then merge from whichever is defined by your\nconfig.\n\nAnd they're usually called \"local branches\" if you differentiating them\nfrom remote tracking branches, or just \"branches\" otherwise.\n\n> BTW, again, why does git clone not have an option to just create all\n> of the \"working versions\" (better name needed) of tracking branches?\n\nI don't recall anybody asking for it, yet. I think the idea is that\nthose branches would just be clutter. If you want to work on something,\nit's easy enough to just start a local version of the branch:\n\n  git checkout -b topic origin/topic\n\n-Peff\n"},{"id":"34734","messageId":"17876.54845.708466.669437@lisa.zopyra.com","threadId":"6836","inReplyTo":"20070215214352.GA2980@coredump.intra.peff.net","subject":"Re: Dangers of working on a tracking branch","fromName":"Bill Lear","fromEmail":"rael@zopyra.com","sentAt":"2007-02-15T21:53:01Z","receivedAt":"2007-02-15T21:53:01Z","isPatch":false,"sender":{"key":"rael@zopyra.com","avatar":"https://gravatar.com/avatar/c4f2d2790ca3828d3b4e7dfebabf61d2fe94fd82fa49cdac2a5295dd2d46a874?d=mp&s=160"},"body":"On Thursday, February 15, 2007 at 16:43:52 (-0500) Jeff King writes:\n>On Thu, Feb 15, 2007 at 03:21:38PM -0600, Bill Lear wrote:\n>\n>> Ok, so I break the model, what is the harm in that?  Can I no longer\n>> pull from or push to the remote branch?  Do I corrupt something\n>> locally?  Does something else break?  I'm trying to formulate an\n>> explanation to our users why the 1.5 way is superior and I can't just\n>> say \"if you do that you break the model\".\n>\n>The commits you make will not actually go onto that tracking branch;\n>they will be part of a \"detached HEAD\" (that is, your HEAD doesn't point\n>to _any_ branch). Once you check out a different branch, you will\n>potentially lose those commits (actually, they will still be available\n>through your reflog, but you will have to know to look for them there).\n\nIs this really the way 1.4.4.1 works?  I have (mistakenly) been\nworking on my tracking branch, committing to it, pushing it, pulling\nin from elsewhere, shifting to new branches, etc., and I haven't lost\nanything, and can't see what harm I've done...\n\n>> BTW, again, why does git clone not have an option to just create all\n>> of the \"working versions\" (better name needed) of tracking branches?\n>\n>I don't recall anybody asking for it, yet. I think the idea is that\n>those branches would just be clutter. If you want to work on something,\n>it's easy enough to just start a local version of the branch:\n>\n>  git checkout -b topic origin/topic\n\nSure, it is easy, but it's surprising to (our) users when they\ndo a clone and can't \"jump right in\", and have to spend 3 seconds\ndoing the above...\n\n\nBill\n"},{"id":"34735","messageId":"20070215215816.GA3757@coredump.intra.peff.net","threadId":"6836","inReplyTo":"17876.54845.708466.669437@lisa.zopyra.com","subject":"Re: Dangers of working on a tracking branch","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-02-15T21:58:16Z","receivedAt":"2007-02-15T21:58:16Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Feb 15, 2007 at 03:53:01PM -0600, Bill Lear wrote:\n\n> Is this really the way 1.4.4.1 works?  I have (mistakenly) been\n> working on my tracking branch, committing to it, pushing it, pulling\n> in from elsewhere, shifting to new branches, etc., and I haven't lost\n> anything, and can't see what harm I've done...\n\nSorry, I thought you were talking about v1.5. v1.4.* does not have the\ndetached HEAD feature, and the default layout is to keep tracking and\nlocal branches in the same namespace. This means that you can checkout\nand commit to a tracking branch just as a local branch, and all changes\nwill be saved. It will only bite you later, when you try to fetch into\nthat tracking branch and realize that the fetch is not a fast-forward\n(remember the troubles you were having with fetches and pushes last\nweek? Those were caused by working on the tracking branches).\n\nThose branches were moved to a separate namespace in v1.5 so that it's\nharder to accidentally commit to them.\n\n> >  git checkout -b topic origin/topic\n> \n> Sure, it is easy, but it's surprising to (our) users when they\n> do a clone and can't \"jump right in\", and have to spend 3 seconds\n> doing the above...\n\nFair enough. It should be pretty simple to implement; why don't you try\nworking up a patch? :)\n\n-Peff\n"},{"id":"34736","messageId":"17876.55542.236594.121347@lisa.zopyra.com","threadId":"6836","inReplyTo":"20070215215816.GA3757@coredump.intra.peff.net","subject":"Re: Dangers of working on a tracking branch","fromName":"Bill Lear","fromEmail":"rael@zopyra.com","sentAt":"2007-02-15T22:04:38Z","receivedAt":"2007-02-15T22:04:38Z","isPatch":false,"sender":{"key":"rael@zopyra.com","avatar":"https://gravatar.com/avatar/c4f2d2790ca3828d3b4e7dfebabf61d2fe94fd82fa49cdac2a5295dd2d46a874?d=mp&s=160"},"body":"On Thursday, February 15, 2007 at 16:58:16 (-0500) Jeff King writes:\n>On Thu, Feb 15, 2007 at 03:53:01PM -0600, Bill Lear wrote:\n>\n>> Is this really the way 1.4.4.1 works?  I have (mistakenly) been\n>> working on my tracking branch, committing to it, pushing it, pulling\n>> in from elsewhere, shifting to new branches, etc., and I haven't lost\n>> anything, and can't see what harm I've done...\n>\n>Sorry, I thought you were talking about v1.5. v1.4.* does not have the\n>detached HEAD feature, and the default layout is to keep tracking and\n>local branches in the same namespace. This means that you can checkout\n>and commit to a tracking branch just as a local branch, and all changes\n>will be saved. It will only bite you later, when you try to fetch into\n>that tracking branch and realize that the fetch is not a fast-forward\n>(remember the troubles you were having with fetches and pushes last\n>week? Those were caused by working on the tracking branches).\n\nOk, just wanted confirmation of my (in)sanity.\n\n>> >  git checkout -b topic origin/topic\n>> \n>> Sure, it is easy, but it's surprising to (our) users when they\n>> do a clone and can't \"jump right in\", and have to spend 3 seconds\n>> doing the above...\n>\n>Fair enough. It should be pretty simple to implement; why don't you try\n>working up a patch? :)\n\nWell, I seriously thought about it, but the git-clone code is pretty\ndense.  It might be educational though, and since I'm the only one\nwho wants it ... might be worth a shot.\n\nThank you for your help.\n\n\nBill\n"},{"id":"34737","messageId":"20070215220634.GA3833@coredump.intra.peff.net","threadId":"6836","inReplyTo":"20070215215816.GA3757@coredump.intra.peff.net","subject":"Re: Dangers of working on a tracking branch","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-02-15T22:06:34Z","receivedAt":"2007-02-15T22:06:34Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Feb 15, 2007 at 04:58:16PM -0500, Jeff King wrote:\n\n> Fair enough. It should be pretty simple to implement; why don't you try\n> working up a patch? :)\n\nRe-reading this, it sounds a little harsh. I meant less \"screw you, if\nyou want it, make a patch\" and more \"I don't have time to work on this\nnow, but I would be happy to help guide you in making a patch.\"\n\n-Peff\n"},{"id":"34738","messageId":"20070215220918.GB27526@spearce.org","threadId":"6836","inReplyTo":"17876.55542.236594.121347@lisa.zopyra.com","subject":"Re: Dangers of working on a tracking branch","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-02-15T22:09:18Z","receivedAt":"2007-02-15T22:09:18Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Bill Lear <rael@zopyra.com> wrote:\n> On Thursday, February 15, 2007 at 16:58:16 (-0500) Jeff King writes:\n> >On Thu, Feb 15, 2007 at 03:53:01PM -0600, Bill Lear wrote:\n> >> Sure, it is easy, but it's surprising to (our) users when they\n> >> do a clone and can't \"jump right in\", and have to spend 3 seconds\n> >> doing the above...\n> >\n> >Fair enough. It should be pretty simple to implement; why don't you try\n> >working up a patch? :)\n> \n> Well, I seriously thought about it, but the git-clone code is pretty\n> dense.  It might be educational though, and since I'm the only one\n> who wants it ... might be worth a shot.\n\nCareful.\n\nLets say you patch git-clone to create these branches under\nrefs/heads, and also under refs/remotes/origin.  Now someone else\nmodifies one of those branches, and you do a git-fetch to get the\nlatest.  The tracking branch under refs/remotes/origin would update,\nbut not the one in refs/heads.  Which means \"jumping right in\" may\nactually cost you a lot more time, because you are now starting on\nsomething that is several days old.\n\n-- \nShawn.\n"},{"id":"34739","messageId":"Pine.LNX.4.64.0702151651440.1757@xanadu.home","threadId":"6836","inReplyTo":"17876.52962.662946.582507@lisa.zopyra.com","subject":"Re: Dangers of working on a tracking branch","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-02-15T22:14:50Z","receivedAt":"2007-02-15T22:14:50Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Thu, 15 Feb 2007, Bill Lear wrote:\n\n> On Thursday, February 15, 2007 at 16:00:23 (-0500) Nicolas Pitre writes:\n> >On Thu, 15 Feb 2007, Bill Lear wrote:\n> >\n> >> We are about to switch to git 1.5 from git 1.4.4.1.  I cannot remember\n> >> if someone posted about this, but what is the danger of working on a\n> >> tracking branch --- there are abundant cautions about doing this, but\n> >> I can't recall and can't find the reason this is bad.\n> >\n> >A tracking branch is supposed to be a local mirror of what is available \n> >remotely.  If you commit local changes to it then you break that model.\n> \n> Ok, so I break the model, what is the harm in that?  Can I no longer\n> pull from or push to the remote branch?  Do I corrupt something\n> locally?  Does something else break?  I'm trying to formulate an\n> explanation to our users why the 1.5 way is superior and I can't just\n> say \"if you do that you break the model\".\n\nIf you commit on top of a tracking branch, then you won't be ablt to \nupdate that branch with remote changes because the tracking branch will \ncontain local changes that the remote doesn't have.  In other words, the \nremote end won't be able to determine the set of changes you are \nmissing to send you only those missing changes.\n\nAt that point it is still possible to do the reverse, i.e. push your \nlocal changes to the remote then both local and remote branches will be \nin sync.  But that works only if the remote was not updated by someone \nelse.  If the remote was updated by someone else, then you fall into the \nsame situation as if you committed on top of a tracking branch and you \ntry to fetch, because it is then impossible for you to determine what \nthe remote is lacking since you won't find the remote changes in your \nlocal repository.  You are then stuck in a dead lock.\n\nNow there is of course a way to force a push or a fetch even if the \nabove scenarios occur.  But if you force the push then the remote \nchanges that you don't have will be lost.  If you force a fetch then \nyour local changes that the remote doesn't have will be lost.\n\nThis is why it is better to have a tracking branch that is modified only \nby fetching remote changes only.  When you make a local copy of that \nbranch and commit changes to that work branch, then you can push those \nchanges to update the remote branch.  And if the remote branch has \nchanged then you have the possibility of updating the tracking branch \nwith the remote changes you don't have yet, merge them into your local \ncopy with your work, and reattempt the push.  But that works fine only \nif the tracking branch is always a subset of what the remote has.\n\n\nNicolas\n"},{"id":"34741","messageId":"17876.57113.528430.800897@lisa.zopyra.com","threadId":"6836","inReplyTo":"20070215220634.GA3833@coredump.intra.peff.net","subject":"Re: Dangers of working on a tracking branch","fromName":"Bill Lear","fromEmail":"rael@zopyra.com","sentAt":"2007-02-15T22:30:49Z","receivedAt":"2007-02-15T22:30:49Z","isPatch":false,"sender":{"key":"rael@zopyra.com","avatar":"https://gravatar.com/avatar/c4f2d2790ca3828d3b4e7dfebabf61d2fe94fd82fa49cdac2a5295dd2d46a874?d=mp&s=160"},"body":"On Thursday, February 15, 2007 at 17:06:34 (-0500) Jeff King writes:\n>On Thu, Feb 15, 2007 at 04:58:16PM -0500, Jeff King wrote:\n>\n>> Fair enough. It should be pretty simple to implement; why don't you try\n>> working up a patch? :)\n>\n>Re-reading this, it sounds a little harsh. I meant less \"screw you, if\n>you want it, make a patch\" and more \"I don't have time to work on this\n>now, but I would be happy to help guide you in making a patch.\"\n\nUnderstood perfectly the first time, even with the smiley. :)\n\n\nBill\n"},{"id":"34743","messageId":"17876.57692.818802.89118@lisa.zopyra.com","threadId":"6836","inReplyTo":"20070215220918.GB27526@spearce.org","subject":"Re: Dangers of working on a tracking branch","fromName":"Bill Lear","fromEmail":"rael@zopyra.com","sentAt":"2007-02-15T22:40:28Z","receivedAt":"2007-02-15T22:40:28Z","isPatch":false,"sender":{"key":"rael@zopyra.com","avatar":"https://gravatar.com/avatar/c4f2d2790ca3828d3b4e7dfebabf61d2fe94fd82fa49cdac2a5295dd2d46a874?d=mp&s=160"},"body":"On Thursday, February 15, 2007 at 17:09:18 (-0500) Shawn O. Pearce writes:\n>...\n>Lets say you patch git-clone to create these branches under\n>refs/heads, and also under refs/remotes/origin.  Now someone else\n>modifies one of those branches, and you do a git-fetch to get the\n>latest.  The tracking branch under refs/remotes/origin would update,\n>but not the one in refs/heads.  Which means \"jumping right in\" may\n>actually cost you a lot more time, because you are now starting on\n>something that is several days old.\n\nGranted, but this would be the same as creating the branch by hand,\nthen going rock-climbing over the weekend, while my colleagues toiled,\nand coming back on Monday to find 15 checkins on that branch, right?\n\nAt which point I could .... rebase?  Do a pull?\n\n\nBill\n"},{"id":"34744","messageId":"20070215224902.GB27992@spearce.org","threadId":"6836","inReplyTo":"17876.57692.818802.89118@lisa.zopyra.com","subject":"Re: Dangers of working on a tracking branch","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-02-15T22:49:02Z","receivedAt":"2007-02-15T22:49:02Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Bill Lear <rael@zopyra.com> wrote:\n> On Thursday, February 15, 2007 at 17:09:18 (-0500) Shawn O. Pearce writes:\n> >...\n> >Lets say you patch git-clone to create these branches under\n> >refs/heads, and also under refs/remotes/origin.  Now someone else\n> >modifies one of those branches, and you do a git-fetch to get the\n> >latest.  The tracking branch under refs/remotes/origin would update,\n> >but not the one in refs/heads.  Which means \"jumping right in\" may\n> >actually cost you a lot more time, because you are now starting on\n> >something that is several days old.\n> \n> Granted, but this would be the same as creating the branch by hand,\n> then going rock-climbing over the weekend, while my colleagues toiled,\n> and coming back on Monday to find 15 checkins on that branch, right?\n\nYes.  Although if you pull something like that, your colleagues\nmay also be muttering things about you near the water cooler...\nSo Git may be the least of your problems.  ;-)\n \n> At which point I could .... rebase?  Do a pull?\n\nRebase or pull, either would work.  Rebase would clutter the\nhistory less (no merge) but also tosses some history (no merge).\nIts a tossup.\n\nAll I was trying to say was this may be more likely to happen,\nas you will clone, work in that repository for a couple of weeks,\nthen get told to look at the `frotz` branch, as it has all the cool\nstuff you were looking for.  You peek at refs/heads/frotz, and\nit has some cool stuff, but its 2 weeks out of date.  Unless you\nremember to pull `origin/frotz` to `frotz` first, you might spend\na while looking at stale code.\n\n-- \nShawn.\n"},{"id":"34757","messageId":"er333i$787$1@sea.gmane.org","threadId":"6836","inReplyTo":"17876.53654.426022.454712@lisa.zopyra.com","subject":"Re: Dangers of working on a tracking branch","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-02-16T02:00:04Z","receivedAt":"2007-02-16T02:00:04Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Bill Lear wrote:\n\n> On Thursday, February 15, 2007 at 15:21:38 (-0600) Bill Lear writes:\n>>On Thursday, February 15, 2007 at 16:00:23 (-0500) Nicolas Pitre writes:\n>>>On Thu, 15 Feb 2007, Bill Lear wrote:\n>>>\n>>>> We are about to switch to git 1.5 from git 1.4.4.1.  I cannot remember\n>>>> if someone posted about this, but what is the danger of working on a\n>>>> tracking branch --- there are abundant cautions about doing this, but\n>>>> I can't recall and can't find the reason this is bad.\n>>>\n>>>A tracking branch is supposed to be a local mirror of what is available \n>>>remotely.  If you commit local changes to it then you break that model.\n>>\n>>Ok, so I break the model, what is the harm in that?  Can I no longer\n>>pull from or push to the remote branch?  Do I corrupt something\n>>locally?  Does something else break?  I'm trying to formulate an\n>>explanation to our users why the 1.5 way is superior and I can't just\n>>say \"if you do that you break the model\".\n\nYou cannot fetch or push to the remote branch if you made some commits\non the tracking branch (\"broke the model\") and remote branch has other\ncommits. You can force the issue, but then either remote (for push)\nor local (for fetch) commits would be lost.\n\nSidenote: for some branches you have to skip fast-forward check, because\nthey have rewritten history (e.g. pu branch in git.git).\n \n> BTW, my ignorant assumption is that for merging to take place, git\n> requires two branches, so 'git pull' will fetch into the tracking\n> branch and then merge onto your ... uh ... whatever the name of the\n> working version of your tracking branch is.\n\nBut one of those branches can be temporary \"branch\" FETCH_HEAD (if you\nuse \"git pull <URL>\" syntax, and do not use tracking (remote) branches).\n\n> BTW, again, why does git clone not have an option to just create all\n> of the \"working versions\" (better name needed) of tracking branches?\n\nBecause usually you work with one branch with tracking (remote) + local\nbranch workflow; I think with multiple branches you usually use temporary\nfeature branches...\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"34799","messageId":"17877.51730.418633.750922@lisa.zopyra.com","threadId":"6836","inReplyTo":"er333i$787$1@sea.gmane.org","subject":"Re: Dangers of working on a tracking branch","fromName":"Bill Lear","fromEmail":"rael@zopyra.com","sentAt":"2007-02-16T15:13:22Z","receivedAt":"2007-02-16T15:13:22Z","isPatch":false,"sender":{"key":"rael@zopyra.com","avatar":"https://gravatar.com/avatar/c4f2d2790ca3828d3b4e7dfebabf61d2fe94fd82fa49cdac2a5295dd2d46a874?d=mp&s=160"},"body":"On Friday, February 16, 2007 at 03:00:04 (+0100) Jakub Narebski writes:\n>Bill Lear wrote:\n>\n>> On Thursday, February 15, 2007 at 15:21:38 (-0600) Bill Lear writes:\n>>>On Thursday, February 15, 2007 at 16:00:23 (-0500) Nicolas Pitre writes:\n>>>>On Thu, 15 Feb 2007, Bill Lear wrote:\n>>>>\n>>>>> We are about to switch to git 1.5 from git 1.4.4.1.  I cannot remember\n>>>>> if someone posted about this, but what is the danger of working on a\n>>>>> tracking branch --- there are abundant cautions about doing this, but\n>>>>> I can't recall and can't find the reason this is bad.\n>>>>\n>>>>A tracking branch is supposed to be a local mirror of what is available \n>>>>remotely.  If you commit local changes to it then you break that model.\n>>>\n>>>Ok, so I break the model, what is the harm in that?  Can I no longer\n>>>pull from or push to the remote branch?  Do I corrupt something\n>>>locally?  Does something else break?  I'm trying to formulate an\n>>>explanation to our users why the 1.5 way is superior and I can't just\n>>>say \"if you do that you break the model\".\n>\n>You cannot fetch or push to the remote branch if you made some commits\n>on the tracking branch (\"broke the model\") and remote branch has other\n>commits. You can force the issue, but then either remote (for push)\n>or local (for fetch) commits would be lost.\n\nOk, I'm trying to come up with an experiment that verifies this, so\nI can give a concrete example to our developers.\n\nI don't seem to be able to get it to fail, but I sure remember having\nsevere problems with this in practice.  Here is my attempt, again with\ngit 1.4.4.1:\n\n# Create my repo and add a file A\n% mkdir my_repo\n% cd my_repo\n% git init-db\ndefaulting to local storage area\n% echo A > A\n% git add A && git commit -a -m \"Add A\"\nCommitting initial tree f53c91092dbda83f3565e78c285f3e2ab0cfd968\n\n# Create a peer repo and add a file B\n% cd ..\n% mkdir peer_repo\n% cd peer_repo/\n% git init-db\ndefaulting to local storage area\n% echo B > B\n% git add B && git commit -a -m \"Add B\"\nCommitting initial tree bfcfa4ca04d80d4b092e022ad163e82ca0f4a34f\n\n# Create a topic branch in peer repo and add file C\n% git checkout -b topic\n% echo C > C\n% git add C && git commit -a -m \"Add C\"\n\n# Go back to my repo and fetch peer's topic branch\n% cd ../my_repo/\n% git fetch ../peer_repo topic:topic\nwarning: no common commits\nremote: Generating pack...\nremote: Done counting 6 objects.\nremote: Deltifying 6 objects.\nremote: /6) done/6) done\nUnpacking 6 objects\nremote: Total 6, written 6 (delta 0), reused 0 (delta 0)\n 100% (6/6) done\n* refs/heads/topic: storing branch 'topic' of ../peer_repo\n  commit: af3ab53\n\n# In my repo, checkout topic and change B\n% git checkout topic\n% echo \"Change B\" >> B\n% git commit -a -m \"Change B\"\n\n# Go back to peer repo and change C\n% cd ../peer_repo/\n% echo \"Change C\" >> C\n% git commit -a -m \"Change C\"\n\n# Go back to my repo and pull peer's topic branch\n% cd ../my_repo\n% git pull ../peer_repo topic:topic\nremote: Generating pack...\nremote: Done counting 5 objects.\nremote: Result has 3 objects.\nremote: Deltifying 3 objects.\nremote:  100% (3/3) done\nremote: Total 3, written 3 (delta 0), reused 0 (delta 0)\nUnpacking 3 objects\n 100% (3/3) done\n* refs/heads/topic: not updating to non-fast forward branch 'topic' of ../peer_repo\n  old...new: d3cf979...9e36a9a\nTrying really trivial in-index merge...\nWonderful.\nIn-index merge\n C |    1 +\n 1 files changed, 1 insertions(+), 0 deletions(-)\n\nSo, why does it say \"not updating to non-fast forward branch\", yet\nit does the merge and gets the changes anyway?\n\n# Seem to have gotten the changes into my_repo anyway:\n% git branch\n  master\n* topic\n% cat B C\nB\nChange B\nC\nChange C\n\nI'm trying to come up with a white-board presentation I can give to\nthe group this afternoon and they are a contumacious bunch.\n\n\nBill\n"},{"id":"34801","messageId":"20070216152130.GA7086@coredump.intra.peff.net","threadId":"6836","inReplyTo":"17877.51730.418633.750922@lisa.zopyra.com","subject":"Re: Dangers of working on a tracking branch","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-02-16T15:21:30Z","receivedAt":"2007-02-16T15:21:30Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Feb 16, 2007 at 09:13:22AM -0600, Bill Lear wrote:\n\n> % git pull ../peer_repo topic:topic\n> [...]\n> * refs/heads/topic: not updating to non-fast forward branch 'topic' of ../peer_repo\n> [...]\n> So, why does it say \"not updating to non-fast forward branch\", yet\n> it does the merge and gets the changes anyway?\n\nBecause your pull command really means \"merge in the topic branch from\npeer_repo, and while you're at it, store it in my local tracking branch\ntopic\". Remember that pull is really a fetch+merge. But the fetch is\nactually doing _two_ things: putting the fetched branch into FETCH_HEAD,\nand putting it in into refs/heads/topic. The latter fails (because of a\nnon-fastforward), but pull actually uses the FETCH_HEAD results to\ndo the merge.\n\nYes, this seems overly complex for what you're doing, but the reason for\nFETCH_HEAD is to support pulls when you _don't_ have a tracking branch\nat all (i.e., 'git pull ../peer_repo topic').\n\n-Peff\n"},{"id":"34802","messageId":"17877.52593.509791.685008@lisa.zopyra.com","threadId":"6836","inReplyTo":"20070216152130.GA7086@coredump.intra.peff.net","subject":"Re: Dangers of working on a tracking branch","fromName":"Bill Lear","fromEmail":"rael@zopyra.com","sentAt":"2007-02-16T15:27:45Z","receivedAt":"2007-02-16T15:27:45Z","isPatch":false,"sender":{"key":"rael@zopyra.com","avatar":"https://gravatar.com/avatar/c4f2d2790ca3828d3b4e7dfebabf61d2fe94fd82fa49cdac2a5295dd2d46a874?d=mp&s=160"},"body":"On Friday, February 16, 2007 at 10:21:30 (-0500) Jeff King writes:\n>On Fri, Feb 16, 2007 at 09:13:22AM -0600, Bill Lear wrote:\n>\n>> % git pull ../peer_repo topic:topic\n>> [...]\n>> * refs/heads/topic: not updating to non-fast forward branch 'topic' of ../peer_repo\n>> [...]\n>> So, why does it say \"not updating to non-fast forward branch\", yet\n>> it does the merge and gets the changes anyway?\n>\n>Because your pull command really means \"merge in the topic branch from\n>peer_repo, and while you're at it, store it in my local tracking branch\n>topic\". Remember that pull is really a fetch+merge. But the fetch is\n>actually doing _two_ things: putting the fetched branch into FETCH_HEAD,\n>and putting it in into refs/heads/topic. The latter fails (because of a\n>non-fastforward), but pull actually uses the FETCH_HEAD results to\n>do the merge.\n>\n>Yes, this seems overly complex for what you're doing, but the reason for\n>FETCH_HEAD is to support pulls when you _don't_ have a tracking branch\n>at all (i.e., 'git pull ../peer_repo topic').\n\nOk, fair enough, but then I guess I'm back to my original question:\nhow can I give a concrete demonstration to our developers that this is\na bad thing?\n\nThis is not 100% required, so if you are tired of answering my\nincessant questions, feel free to decline.  I will be able to get our\ngroup to move forward, simply because we need to try to stay current,\nand there are lots of improvements in git besides this issue.\n\n\nBill\n"},{"id":"34803","messageId":"20070216155251.GA7183@coredump.intra.peff.net","threadId":"6836","inReplyTo":"17877.52593.509791.685008@lisa.zopyra.com","subject":"Re: Dangers of working on a tracking branch","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-02-16T15:52:51Z","receivedAt":"2007-02-16T15:52:51Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Feb 16, 2007 at 09:27:45AM -0600, Bill Lear wrote:\n\n> Ok, fair enough, but then I guess I'm back to my original question:\n> how can I give a concrete demonstration to our developers that this is\n> a bad thing?\n\nI think it will always work with the example you gave, because you are\nsimultaneously fetching into the tracking branch (which fails) and\nmerging from FETCH_HEAD (which succeeds) into that same tracking branch.\n\nAt best, though, the tracking branch you have is pointless (since you\nimmediately overwrite it anyway).  The point of a tracking branch\ngenerally is to allow you to do operations against your peer's idea of\nthe branch (e.g., diffing against upstream's version of \"topic\"). But\nyou can't do that, because \"topic\" always contains your topic, not\nupstream's. In effect, your pull becomes one without a tracking branch\nat all.\n\nThis will also get you on a push, where there is no merging at all, just\na fast-forward (or failure). IIRC, you ran into problems before because\nyou were trying to push into your public repo from your private, but the\ntwo had divergent branches. So I think to illustrate the problem you had\nbefore, you actually need an intermediate repo which has you fetch from\nand push to.\n\n-Peff\n"},{"id":"34805","messageId":"8aa486160702160810i3d92ba6fy390674dfcc9c584@mail.gmail.com","threadId":"6836","inReplyTo":"17877.52593.509791.685008@lisa.zopyra.com","subject":"Re: Dangers of working on a tracking branch","fromName":"Santi Béjar","fromEmail":"sbejar@gmail.com","sentAt":"2007-02-16T16:10:57Z","receivedAt":"2007-02-16T16:10:57Z","isPatch":false,"sender":{"key":"santi@agolina.net","avatar":null},"body":"On 2/16/07, Bill Lear <rael@zopyra.com> wrote:\n> On Friday, February 16, 2007 at 10:21:30 (-0500) Jeff King writes:\n> >On Fri, Feb 16, 2007 at 09:13:22AM -0600, Bill Lear wrote:\n> >\n> >> % git pull ../peer_repo topic:topic\n> >> [...]\n> >> * refs/heads/topic: not updating to non-fast forward branch 'topic' of ../peer_repo\n> >> [...]\n> >> So, why does it say \"not updating to non-fast forward branch\", yet\n> >> it does the merge and gets the changes anyway?\n> >\n> >Because your pull command really means \"merge in the topic branch from\n> >peer_repo, and while you're at it, store it in my local tracking branch\n> >topic\". Remember that pull is really a fetch+merge. But the fetch is\n> >actually doing _two_ things: putting the fetched branch into FETCH_HEAD,\n> >and putting it in into refs/heads/topic. The latter fails (because of a\n> >non-fastforward), but pull actually uses the FETCH_HEAD results to\n> >do the merge.\n> >\n> >Yes, this seems overly complex for what you're doing, but the reason for\n> >FETCH_HEAD is to support pulls when you _don't_ have a tracking branch\n> >at all (i.e., 'git pull ../peer_repo topic').\n>\n> Ok, fair enough, but then I guess I'm back to my original question:\n> how can I give a concrete demonstration to our developers that this is\n> a bad thing?\n>\n\nIt no longer works with recent git, as of v1.4.4.1-37-gd25c26e. Now\ngit-fetch exit with a non-zero status when fast-forward check fails,\nso the merge does not happen.\n\nSanti\n"},{"id":"34807","messageId":"alpine.LRH.0.82.0702161044100.18370@xanadu.home","threadId":"6836","inReplyTo":"17877.51730.418633.750922@lisa.zopyra.com","subject":"Re: Dangers of working on a tracking branch","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-02-16T16:34:01Z","receivedAt":"2007-02-16T16:34:01Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Fri, 16 Feb 2007, Bill Lear wrote:\n\n> Ok, I'm trying to come up with an experiment that verifies this, so\n> I can give a concrete example to our developers.\n> \n> I don't seem to be able to get it to fail, but I sure remember having\n> severe problems with this in practice.\n\nTry this:\n\n\t# create first repository\n\tmkdir foo\n\tcd foo\n\tgit init-db\n\techo FOO > biz\n\tgit add biz\n\tgit commit -a -m \"commit 1 in foo\"\n\n\t# clone this repository elsewhere\n\tcd ..\n\tgit clone foo bar\n\tcd bar\n\n\t# modify the tracking branch (origin in this case)\n\tgit checkout origin\n\techo BAR > biz\n\tgit commit -a -m \"modify tracking branch in bar\"\n\n\t# go back to original repo and modify it\n\tcd ../foo\n\techo BAZ > biz\n\tgit commit -a -m \"modify master branch in foo\"\n\n\t# now back to the cloned repo\n\tcd ../bar\n\tgit fetch\t# it fails\n\tgit push\t# itfails\n\tgit pull\t# it almost performs the merge but...\n\nBecause you now have a conflict to resolve, you might wish to inspect \nwhat the remote state actually is.  But because you modified your origin \nbranch you don't have any pristine version of what the remote has, \nexcept maybe the MERGE_HEAD.  But if you work in a complex project, \nMERGE_HEAD will not stay there for long if you move around.\n\nImagine that you want to move to another branch, say master, because \nright now you don't feel like resolving this ultra complex merge:\n\n\tgit checkout master\t# it fails (unresolved merge)\n\tgit checkout -f\t\t# succeeds, discarding the merge\n\nBut at this point you still don't have any way to look at the remote's \ncontent.  If instead the origin branch was untouched and the work had \noccurred in the master branch, then you could git-log the origin branch, \nyou could git-diff your master branch with the origin branch, you could \neven checkout the origin content to test it, etc.  But since you added \ncommits on top of the origin branch then you cannot do any of that \nbecause it is impossible to update the origin branch with the remote \nstuff.  Well you can force it of course:\n\n\tgit fetch -f\n\nBut by doing so you lose all the work you committed on top of origin.\n\nBTW I checked out v1.4.4.1 to verify the above operations..... and this \nGIT version really feels odd compared to v1.5.0\n\n\nNicolas\n"},{"id":"34809","messageId":"17877.56939.79093.519874@lisa.zopyra.com","threadId":"6836","inReplyTo":"alpine.LRH.0.82.0702161044100.18370@xanadu.home","subject":"Re: Dangers of working on a tracking branch","fromName":"Bill Lear","fromEmail":"rael@zopyra.com","sentAt":"2007-02-16T16:40:11Z","receivedAt":"2007-02-16T16:40:11Z","isPatch":false,"sender":{"key":"rael@zopyra.com","avatar":"https://gravatar.com/avatar/c4f2d2790ca3828d3b4e7dfebabf61d2fe94fd82fa49cdac2a5295dd2d46a874?d=mp&s=160"},"body":"On Friday, February 16, 2007 at 11:34:01 (-0500) Nicolas Pitre writes:\n>On Fri, 16 Feb 2007, Bill Lear wrote:\n>\n>> Ok, I'm trying to come up with an experiment that verifies this, so\n>> I can give a concrete example to our developers.\n>> \n>> I don't seem to be able to get it to fail, but I sure remember having\n>> severe problems with this in practice.\n>\n>Try this:\n\nOk, that's basically what I was looking for --- incontrovertible\nevidence from \"them\" (a git expert --- not me).  Thanks very much\nNicolas.\n\n\nBill\n"}]}