{"thread":{"id":"43403","subject":"Re: Rationale for the \"Never commit to the right side of a Pull line\" rule","startedAt":"2006-10-26T16:47:43Z","lastAt":"2006-10-27T08:56:00Z","messageCount":5,"participants":["Jakub Narebski","Karl Hasselström","Jerome Lovy","Luben Tuikov","Linus Torvalds"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"295557","messageId":"ehqp1u$j4$1@sea.gmane.org","threadId":"43403","inReplyTo":null,"subject":"Rationale for the \"Never commit to the right side of a Pull line\" rule","fromName":"Jerome Lovy","fromEmail":"t2a2e9z8ncbs9qg@brefemail.com","sentAt":"2006-10-26T16:47:43Z","receivedAt":"2006-10-26T16:47:43Z","isPatch":false,"sender":{"key":"t2a2e9z8ncbs9qg@brefemail.com","avatar":null},"body":"Hi,\n\nCould someone please point me to / give me the rationale for the \"Never \ncommit to the right side of a Pull line\" rule ?\n\nI found the rule in the second Note of the git-fetch man-page (eg \nhttp://www.kernel.org/pub/software/scm/git/docs/git-fetch.html).\n\nIt's been taken over in _bold letters_ by X.Org/freedesktop.org in their \n\"UsingGit\" document (http://freedesktop.org/wiki/UsingGit).\n\nIn both places though, I don't see any explanation, but rather a \ncommandment ;-) . Am I missing the ovious ?\n\nMy candid thoughts: to me the practice recommended here seems \nsubjectively \"cleaner\" indeed, but is it objectively better or even \nessential? Why?\n\nTIA\nJérôme\n"},{"id":"297664","messageId":"Pine.LNX.4.64.0610261003590.3962@g5.osdl.org","threadId":"43403","inReplyTo":"ehqp1u$j4$1@sea.gmane.org","subject":"Re: Rationale for the \"Never commit to the right side of a Pull line\" rule","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-10-26T17:11:50Z","receivedAt":"2006-10-26T17:11:50Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 26 Oct 2006, Jerome Lovy wrote:\n> \n> Could someone please point me to / give me the rationale for the \"Never commit\n> to the right side of a Pull line\" rule ?\n\nIt's not a technical rule per se.\n\nIt's just a way to avoid what will almost inevitably otherwise be a \nhorribly horribly confusing situation.\n\nI say \"almost inevitably\", because if you really have worked with git \nenough, and understand how it works on a very fundamental level, there are \nactually no problems at all with doing so, and maybe you could have \nperfectly fine reasons to break the rule, and commit to a branch that is \nofficially \"maintained in another repository\" and then push it out.\n\nBut it's a good rule in general, just because it makes a certain common \nworkflow explicit. In fact, we really probably should start to always use \nthe \"refs/remote/origin/HEAD\" kind of syntax by default, where you can't \neven _switch_ to the branch maintained in the remote repository, because \nit's not a real branch locally.\n\nSo normally you should consider the \"origin\" branch to be a pointer to \nWHAT YOU FETCHED LAST - and that implies that you shouldn't commit to it, \nbecause then it loses that meaning (now it's \"what you fetched last and \nthen committed your own work on top of\", which is something totally \ndifferent).\n\n"},{"id":"295469","messageId":"20061026172603.GA21256@diana.vm.bytemark.co.uk","threadId":"43403","inReplyTo":"Pine.LNX.4.64.0610261003590.3962@g5.osdl.org","subject":"Re: Rationale for the \"Never commit to the right side of a Pull line\" rule","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2006-10-26T17:26:03Z","receivedAt":"2006-10-26T17:26:03Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2006-10-26 10:11:50 -0700, Linus Torvalds wrote:\n\n> But it's a good rule in general, just because it makes a certain\n> common workflow explicit. In fact, we really probably should start\n> to always use the \"refs/remote/origin/HEAD\" kind of syntax by\n> default, where you can't even _switch_ to the branch maintained in\n> the remote repository, because it's not a real branch locally.\n\nSeconded. I really like having remote branches in their own namespace\nwhere I can't confuse them with my local branches by mistake -- and\nthat the branches of different remotes end up in different separate\nnamespaces.\n\n> So normally you should consider the \"origin\" branch to be a pointer\n> to WHAT YOU FETCHED LAST - and that implies that you shouldn't\n> commit to it, because then it loses that meaning (now it's \"what you\n> fetched last and then committed your own work on top of\", which is\n> something totally different).\n\nDefaulting to --use-separate-remotes would mean not having to explain\nthis to every single confused new user. :-)\n\nIt feels like the right thing to do, because it reduces the amount of\nthings a user has to know about git internals. Until you get to the\nlevel where you can do brain surgery on your repo, the remotes/\nbranches will really _be_ your local read-only mirror of remote\nbranches, and you don't have to be aware of the possibility that they\ncould get out of sync because of local commits.\n\n-- \nKarl Hasselström, kha@treskal.com\n"},{"id":"294632","messageId":"ehqr9t$9rh$1@sea.gmane.org","threadId":"43403","inReplyTo":"ehqp1u$j4$1@sea.gmane.org","subject":"Re: Rationale for the \"Never commit to the right side of a Pull line\" rule","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-26T17:30:15Z","receivedAt":"2006-10-26T17:30:15Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jerome Lovy wrote:\n\n> Could someone please point me to / give me the rationale for the \"Never \n> commit to the right side of a Pull line\" rule ?\n> \n> I found the rule in the second Note of the git-fetch man-page (eg \n> http://www.kernel.org/pub/software/scm/git/docs/git-fetch.html).\n\nBecause git refuses to fetch into branch on top of which there are changes\nwhich are not present in the branch you fetch from (if it is not\nfast-forward case). So commitiing to tracking branches breaks the most\ntypical workflow, i.e. fetch when you want, push when you are ready.\n\ngit-clone --use-separate-remotes takes care of that by putting tracking\nbranches in refs/remotes/, i.e. outside refs/heads/, so you cannot commit\nthere, at least not by accident.\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"297338","messageId":"546144.34624.qm@web31811.mail.mud.yahoo.com","threadId":"43403","inReplyTo":"ehqp1u$j4$1@sea.gmane.org","subject":"Re: Rationale for the \"Never commit to the right side of a Pull line\" rule","fromName":"Luben Tuikov","fromEmail":"ltuikov@yahoo.com","sentAt":"2006-10-27T08:56:00Z","receivedAt":"2006-10-27T08:56:00Z","isPatch":false,"sender":{"key":"ltuikov@yahoo.com","avatar":null},"body":"--- Jerome Lovy <t2a2e9z8ncbs9qg@brefemail.com> wrote:\n> Hi,\n> \n> Could someone please point me to / give me the rationale for the \"Never \n> commit to the right side of a Pull line\" rule ?\n> \n> I found the rule in the second Note of the git-fetch man-page (eg \n> http://www.kernel.org/pub/software/scm/git/docs/git-fetch.html).\n> \n> It's been taken over in _bold letters_ by X.Org/freedesktop.org in their \n> \"UsingGit\" document (http://freedesktop.org/wiki/UsingGit).\n> \n> In both places though, I don't see any explanation, but rather a \n> commandment ;-) . Am I missing the ovious ?\n\nYes, you are missing the obvious and yes it is explained.\nRead the 2nd \"Note\" for the documentation of \"git-fetch\":\n\nhttp://www.kernel.org/pub/software/scm/git/docs/git-fetch.html\n\nQuoted here for convenience:\n\n[NOTE]\nYou never do your own development on branches that appear\non the right hand side of a <refspec> colon on `Pull:` lines;\nthey are to be updated by `git-fetch`.  If you intend to do\ndevelopment derived from a remote branch `B`, have a `Pull:`\nline to track it (i.e. `Pull: B:remote-B`), and have a separate\nbranch `my-B` to do your development on top of it.  The latter\nis created by `git branch my-B remote-B` (or its equivalent `git\ncheckout -b my-B remote-B`).  Run `git fetch` to keep track of\nthe progress of the remote side, and when you see something new\non the remote branch, merge it into your development branch with\n`git pull . remote-B`, while you are on `my-B` branch.\nThe common `Pull: master:origin` mapping of a remote `master`\nbranch to a local `origin` branch, which is then merged to a\nlocal development branch, again typically named `master`, is made\nwhen you run `git clone` for you to follow this pattern.\n\n  Luben\n\n\n> \n> My candid thoughts: to me the practice recommended here seems \n> subjectively \"cleaner\" indeed, but is it objectively better or even \n> essential? Why?\n> \n> TIA\n> Jérôme\n> \n> -\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n> \n"}]}