{"thread":{"id":"1662","subject":"RE: [PATCH] Fix pulling into the same branch.","startedAt":"2005-08-26T18:13:45Z","lastAt":"2005-09-11T23:15:34Z","messageCount":7,"participants":["Luck, Tony","Junio C Hamano","Johannes Schindelin","Linus Torvalds"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"7814","messageId":"B8E391BBE9FE384DAA4C5C003888BE6F043BA469@scsmsx401.amr.corp.intel.com","threadId":"1662","inReplyTo":null,"subject":"RE: [PATCH] Fix pulling into the same branch.","fromName":"Luck, Tony","fromEmail":"tony.luck@intel.com","sentAt":"2005-08-26T18:13:45Z","receivedAt":"2005-08-26T18:13:45Z","isPatch":true,"sender":{"key":"tony.luck@intel.com","avatar":"https://avatars.githubusercontent.com/u/5446021?v=4"},"body":">I am tempted to move this logic to \"git fetch\" instead, because\n>it has the same issue. Tony's \"linus\" branch example has been\n>updated to do a \"git fetch\" instead of \"git pull\" from the\n>earlier description in his howto, but if he happens to be on the\n>\"linus\" branch, he would still have this same problem.\n\nI don't spend much time on the linus branch (just to build an\nupdated cscope database, etc.). I never want to check anything\nin on that branch [sometime I should figure out how use the \"hooks\"\nto keep me from shooting myself in the foot here].\n\n>In the meantime, warning the user about the issue and suggesting\n>how to do the fast-forwarding of the working tree himself in the\n>warning message might be the safest and the most sensible thing\n>to do.\n\nYes please ... a big fat warning with coloured flashing lights\nand explosions from the sound card.\n\n-Tony\n"},{"id":"7835","messageId":"7vzmr43vix.fsf@assigned-by-dhcp.cox.net","threadId":"1662","inReplyTo":"B8E391BBE9FE384DAA4C5C003888BE6F043BA469@scsmsx401.amr.corp.intel.com","subject":"Re: [PATCH] Fix pulling into the same branch.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-08-27T03:31:50Z","receivedAt":"2005-08-27T03:31:50Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Luck, Tony\" writes:\n\n>>In the meantime, warning the user about the issue and suggesting\n>>how to do the fast-forwarding of the working tree himself in the\n>>warning message might be the safest and the most sensible thing\n>>to do.\n>\n> Yes please ... a big fat warning with coloured flashing lights\n> and explosions from the sound card.\n\nYeah, but what to do afterwards? I can see this as an\ncompromise:\n\n * \"git fetch\", just like the updated \"git pull\", reads\n $GIT_DIR/HEAD before it starts its work, and compares it with\n $GIT_DIR/HEAD after it is done. If the --update-head-ok flag\n is not given on the command line, and if the HEAD changed,\n then barf and exit with non-zero status after reverting\n $GIT_DIR/HEAD to its original value. If --update-head-ok is\n given, none of the above check and revert happens.\n\n * \"git pull\" calls \"git fetch\" with the extra flag, and does\n its thing the current way.\n\nSo if you are calling from the command line, \"git fetch linus\",\nwhen you were still on \"linus\" branch (which you do not normally\ndo but just to prevent mistakes), it would trigger the check and\nyour $GIT_DIR/HEAD would stay intact. If you stayed on your own\nbranch, \"git fetch linus\" would continue to just fast forward\n\"linus\" head without touching the working tree.\n\nCome to think of it, it may be cleaner to simply forbid\nfast-forward fetching into the current repository (whether it is\n\"git fetch\" or \"git pull\"). At least in your workflow you do\nnot do that ever anyway.\n\nJohannes, what do you think, as the original advocate of \"push in\nreverse\"?\n"},{"id":"8282","messageId":"Pine.LNX.4.63.0509111153380.32555@wgmdd8.biozentrum.uni-wuerzburg.de","threadId":"1662","inReplyTo":"7vzmr43vix.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Fix pulling into the same branch.","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2005-09-11T09:56:05Z","receivedAt":"2005-09-11T09:56:05Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 26 Aug 2005, Junio C Hamano wrote:\n\n> Come to think of it, it may be cleaner to simply forbid\n> fast-forward fetching into the current repository (whether it is\n> \"git fetch\" or \"git pull\"). At least in your workflow you do\n> not do that ever anyway.\n> \n> Johannes, what do you think, as the original advocate of \"push in\n> reverse\"?\n\nI'm fine with it.\n\nAlthough it might make more sense to check for dirty state, and \nfast-forward only for a clean state (together with a checkout of the new \nHEAD).\n\nCiao,\nDscho\n"},{"id":"8298","messageId":"7vk6hntslb.fsf@assigned-by-dhcp.cox.net","threadId":"1662","inReplyTo":"Pine.LNX.4.63.0509111153380.32555@wgmdd8.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] Fix pulling into the same branch.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-11T17:36:00Z","receivedAt":"2005-09-11T17:36:00Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> On Fri, 26 Aug 2005, Junio C Hamano wrote:\n>\n>> Johannes, what do you think, as the original advocate of \"push in\n>> reverse\"?\n>\n> I'm fine with it.\n\nWow, blast from the past ;-).\n\n> Although it might make more sense to check for dirty state, and \n> fast-forward only for a clean state (together with a checkout of the new \n> HEAD).\n\nYes, but the issue becomes how we can reliably tell if a\nrepository is naked or has an associated working tree. I've\nseen people rsync only .git subdirectory of their live working\ntree to publish to a public repository, which means their pulic\nrepository has .git/index file, so it is kind of\ntricky.\n"},{"id":"8303","messageId":"Pine.LNX.4.58.0509111054590.3242@g5.osdl.org","threadId":"1662","inReplyTo":"7vk6hntslb.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Fix pulling into the same branch.","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-09-11T17:58:00Z","receivedAt":"2005-09-11T17:58:00Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 11 Sep 2005, Junio C Hamano wrote:\n> \n> Yes, but the issue becomes how we can reliably tell if a\n> repository is naked or has an associated working tree.\n\nYou can't \"git pull\" into a naked thing anyway. And\n\n\tgit-read-tree -m -u \n\nshould always do the right thing (ie if there is dirty state that would be\nupdated, it will fail gracefully).\n\nOr did I miss something?\n\n\t\tLinus\n"},{"id":"8313","messageId":"7vvf17saza.fsf@assigned-by-dhcp.cox.net","threadId":"1662","inReplyTo":"Pine.LNX.4.58.0509111054590.3242@g5.osdl.org","subject":"Re: [PATCH] Fix pulling into the same branch.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-11T18:41:45Z","receivedAt":"2005-09-11T18:41:45Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> On Sun, 11 Sep 2005, Junio C Hamano wrote:\n>> \n>> Yes, but the issue becomes how we can reliably tell if a\n>> repository is naked or has an associated working tree.\n>\n> You can't \"git pull\" into a naked thing anyway. And\n>\n> \tgit-read-tree -m -u \n>\n> should always do the right thing (ie if there is dirty state that would be\n> updated, it will fail gracefully).\n>\n> Or did I miss something?\n\nNo, I just stated my view poorly.\n\nYou cannot do pull into a naked one, but you can still fetch\ninto it. My comment Johannes was responding to was what to do\nwhen you do 'git fetch' into the repository associated with your\nworking tree and your branch is fast forwarded. We obviously\nwant to prevent it from happening. However, it is OK to do so\nif the fetch is happening into a naked one and I was wondering\nif there is a reliable way to tell that situation and allowing\nthat.\n"},{"id":"8334","messageId":"Pine.LNX.4.63.0509120113380.10414@wgmdd8.biozentrum.uni-wuerzburg.de","threadId":"1662","inReplyTo":"7vk6hntslb.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Fix pulling into the same branch.","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2005-09-11T23:15:34Z","receivedAt":"2005-09-11T23:15:34Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 11 Sep 2005, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > On Fri, 26 Aug 2005, Junio C Hamano wrote:\n> >\n> >> Johannes, what do you think, as the original advocate of \"push in\n> >> reverse\"?\n> >\n> > I'm fine with it.\n> \n> Wow, blast from the past ;-).\n\nSorry, I tried to relax for two weeks. That didn't work, though (pun \nintended).\n\n> > Although it might make more sense to check for dirty state, and \n> > fast-forward only for a clean state (together with a checkout of the new \n> > HEAD).\n> \n> Yes, but the issue becomes how we can reliably tell if a\n> repository is naked or has an associated working tree. I've\n> seen people rsync only .git subdirectory of their live working\n> tree to publish to a public repository, which means their pulic\n> repository has .git/index file, so it is kind of\n> tricky.\n\nI think it is easy to discern the two states \"up to date checkout\" and \n\"dirty checkout or no checkout at all\". But then, you're right: git fetch \nshould not touch the working copy.\n\nCiao,\nDscho\n"}]}