{"thread":{"id":"1647","subject":"RE: cache status after git pull","startedAt":"2005-08-25T20:46:22Z","lastAt":"2005-08-26T18:03:33Z","messageCount":5,"participants":["Luck, Tony","Junio C Hamano","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"7758","messageId":"B8E391BBE9FE384DAA4C5C003888BE6F043B9B85@scsmsx401.amr.corp.intel.com","threadId":"1647","inReplyTo":null,"subject":"RE: cache status after git pull","fromName":"Luck, Tony","fromEmail":"tony.luck@intel.com","sentAt":"2005-08-25T20:46:22Z","receivedAt":"2005-08-25T20:46:22Z","isPatch":false,"sender":{"key":"tony.luck@intel.com","avatar":"https://avatars.githubusercontent.com/u/5446021?v=4"},"body":">To set up \"linus\" short-hand to be updated with \"master\" branch\n>head from Linus, you would do one of the following:\n>\n> * Using new style shorthand\n>\n> $ cat >$GIT_DIR/remotes/linus \\\n> URL: http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/\n> Pull: master:linus\n> $ git fetch linus\n\nThis sounds like it does what I want ... so I'd like to confirm\nbefore wiring this into my scripts and fingers.\n\nWhat I want is to get the latest from kernel.org...linus...master\nand update my .refs/heads/linus with the new SHA1.\n\nI'd like to be able to do that without touching what is in my\nindex, and without changing the state of any checked out files.\n\nIf that is what the above does, then you are my hero for today :-)\n\n-Tony\n"},{"id":"7783","messageId":"7vr7chmqop.fsf_-_@assigned-by-dhcp.cox.net","threadId":"1647","inReplyTo":"B8E391BBE9FE384DAA4C5C003888BE6F043B9B85@scsmsx401.amr.corp.intel.com","subject":"[PATCH] Fix pulling into the same branch.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-08-26T01:29:10Z","receivedAt":"2005-08-26T01:29:10Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Earlier, I said:\n\n Subject: Re: cache status after git pull\n Date: Thu, 25 Aug 2005 13:26:07 -0700\n Message-ID: <7v4q9dvk4g.fsf@assigned-by-dhcp.cox.net>\n\n > 1) Updated my \"linus\" branch:\n >\n > $ git checkout linus && git pull linus\n\n The second command, \"git pull linus\", would internally run \"git\n fetch linus\". It depends on how your shorthand \"linus\" is\n defined, but if it is set to update (either overwrite or\n fast-forward) the \"linus\" branch head, then your HEAD pointer\n would be updated without updating the index and working tree.\n This is bad because now you are telling git that your working\n tree is based on updated \"linus\" branch head, and what you\n _could_ commit on top of it is the same thing as what old\n \"linus\" branch head commit used to have. That's why \"git\n status\" output shows the minefield.\n\n If I keep copies of foreign brahches in $GIT_DIR/refs/heads/\n somewhere, I never checkout those branches in my working tree.\n I always stay in my branches to do my work. I may \"diff\"\n against them to see where I am. Of course I would \"resolve\"\n with them when I feel I am ready.\n\n So, assuming that \"linus\" short-hand is set up to update\n $GIT_DIR/refs/heads/linus with the foreign branch head, the\n above example would have been:\n\n $ git checkout master && git pull linus\n : examine diffs and be convinced what Linus does is always right.\n\nThis \"do not pull into the branch you are on\" is probably a good\nadvice as a workaround, but there is no fundamental reason to\nforbid it. Worse, there is no machinery to even warn about the\nsituation right now.\n\nThis patch is to show my current thinking. Please let me know\nwhat you think.\n\n-jc\n\n------------\nWhen the \"git pull\" command updates the branch head you are\ncurrently on, before doing anything else, first update your\nindex file and the working tree contents to that of the new\nbranch head. Otherwise, the later resolving steps would think\nyour index file is attempting to revert the change between the\noriginal head commit and the updated head commit.\n\nIt uses two-tree fast-forward form of \"read-tree -m -u\" to\nprevent losing whatever local changes you may have in the\nworking tree to do this update. I think this would at least\nmake things safer (a lot safer), and prevent mistakes.\n\nSigned-off-by: Junio C Hamano \n\n---\n\n git-pull-script | 18 ++++++++++++++++++\n 1 files changed, 18 insertions(+), 0 deletions(-)\n\n10f624a7743fc1e29277de9875dbd6a882f2d3b3\ndiff --git a/git-pull-script b/git-pull-script\n--- a/git-pull-script\n+++ b/git-pull-script\n@@ -5,7 +5,25 @@\n # Fetch one or more remote refs and merge it/them into the current HEAD.\n \n . git-sh-setup-script || die \"Not a git archive\"\n+\n+orig_head=$(cat \"$GIT_DIR/HEAD\") || die \"Pulling into a black hole?\"\n git-fetch-script \"$@\" || exit 1\n+\n+curr_head=$(cat \"$GIT_DIR/HEAD\")\n+if test \"$curr_head\" != \"$orig_head\"\n+then\n+\t# The fetch involved updating the current branch.\n+\n+\t# The working tree and the index file is still based on the\n+\t# $orig_head commit, but we are merging into $curr_head.\n+\t# First update the working tree to match $curr_head.\n+\n+\techo >&2 \"Warning: fetch updated the current branch head.\"\n+\techo >&2 \"Warning: fast forwarding your working tree.\"\n+\tgit-read-tree -u -m \"$orig_head\" \"$curr_head\" ||\n+\t\tdie \"You need to first update your working tree.\"\n+fi\n+\n merge_head=$(sed -e 's/\t.*//' \"$GIT_DIR\"/FETCH_HEAD | tr '\\012' ' ')\n merge_name=$(sed -e 's/^[0-9a-f]*\t//' \"$GIT_DIR\"/FETCH_HEAD |\n \t tr '\\012' ' ')\n"},{"id":"7779","messageId":"7vll2pmqnu.fsf@assigned-by-dhcp.cox.net","threadId":"1647","inReplyTo":"B8E391BBE9FE384DAA4C5C003888BE6F043B9B85@scsmsx401.amr.corp.intel.com","subject":"Re: cache status after git pull","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-08-26T01:29:41Z","receivedAt":"2005-08-26T01:29:41Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Luck, Tony\" writes:\n\n> What I want is to get the latest from kernel.org...linus...master\n> and update my .refs/heads/linus with the new SHA1.\n>\n> I'd like to be able to do that without touching what is in my\n> index, and without changing the state of any checked out files.\n>\n> If that is what the above does,...\n\nAt least that is how \"git fetch :\" is designed\nto work, and \"Pull: :\" in a remotes/ shorthand is\ndesigned to reduce typing while doing so. Please bug me if\nthings do not work as advertised.\n"},{"id":"7807","messageId":"Pine.LNX.4.63.0508261501510.18279@wgmdd8.biozentrum.uni-wuerzburg.de","threadId":"1647","inReplyTo":"7vr7chmqop.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-08-26T13:04:43Z","receivedAt":"2005-08-26T13:04:43Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 25 Aug 2005, Junio C Hamano wrote:\n\n> This patch is to show my current thinking. Please let me know\n> what you think.\n\nI like it. As Linus stated, the index originally had a different role from \nwhat it has now, so it really should be an internal git thing, i.e. the \ngit user should not expect the index not to change when pulling.\n\nCiao,\nDscho\n"},{"id":"7813","messageId":"7voe7keft6.fsf@assigned-by-dhcp.cox.net","threadId":"1647","inReplyTo":"Pine.LNX.4.63.0508261501510.18279@wgmdd8.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] Fix pulling into the same branch.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-08-26T18:03:33Z","receivedAt":"2005-08-26T18:03:33Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> I like it. As Linus stated, the index originally had a different role from \n> what it has now, so it really should be an internal git thing, i.e. the \n> git user should not expect the index not to change when pulling.\n\nActually the issue and the way patch addresses it is not limited\nto the index file. The problem is that the relashionship\nbetween your working tree and the $GIT_DIR/HEAD commit changes\nunexpectedly (from the POV of the working tree) when the ref\nbeing updated by the \"push in reverse\" machinery happens to be\nthe head of the branch you are currently on. The working tree\nis supposed to be based on $GIT_DIR/HEAD, but after the \"push in\nreverse\". This fix is about fast forwarding the working tree,\nincluding the checked out files on the filesystem, to the\nupdated head when it happens.\n\nI am tempted to move this logic to \"git fetch\" instead, because\nit has the same issue. Tony's \"linus\" branch example has been\nupdated to do a \"git fetch\" instead of \"git pull\" from the\nearlier description in his howto, but if he happens to be on the\n\"linus\" branch, he would still have this same problem.\n\nOf course, doing this in \"git fetch\" needs to be done a bit more\ncarefully than in \"git pull\", because by definition \"pull\" is a\nfetch followed by merging into the working tree, implying that\nthe repository has an associated working tree. But \"fetch\" by\nitself can be used for a naked repository [*1*], and we should\nnot unconditionally attempt to update the working tree that may\nnot exist.\n\nI am planning to use the lack of index file for this detection,\nbut I've seen some people made an rsync copy of their private\nrepository as a whole to publish, so this heuristic may\nprobabaly break. Maybe the lack of \"$GIT_DIR/index\" and\n$GIT_DIR not ending with \"/.git\" and not being \".git\"? I am\nundecided.\n\nIn the meantime, warning the user about the issue and suggesting\nhow to do the fast-forwarding of the working tree himself in the\nwarning message might be the safest and the most sensible thing\nto do.\n\n\n[Footnote]\n\n*1* Do we want a term in the glossary to mean repositories like\nlinux-2.6.git and git.git that do not have associated working\ntrees?\n"}]}