Re: [PATCH] Fix pulling into the same branch.
"Luck, Tony" <[EMAIL PROTECTED]> writes: >>In the meantime, warning the user about the issue and suggesting >>how to do the fast-forwarding of the working tree himself in the >>warning message might be the safest and the most sensible thing >>to do. > > Yes please ... a big fat warning with coloured flashing lights > and explosions from the sound card. Yeah, but what to do afterwards? I can see this as an compromise: * "git fetch", just like the updated "git pull", reads $GIT_DIR/HEAD before it starts its work, and compares it with $GIT_DIR/HEAD after it is done. If the --update-head-ok flag is not given on the command line, and if the HEAD changed, then barf and exit with non-zero status after reverting $GIT_DIR/HEAD to its original value. If --update-head-ok is given, none of the above check and revert happens. * "git pull" calls "git fetch" with the extra flag, and does its thing the current way. So if you are calling from the command line, "git fetch linus", when you were still on "linus" branch (which you do not normally do but just to prevent mistakes), it would trigger the check and your $GIT_DIR/HEAD would stay intact. If you stayed on your own branch, "git fetch linus" would continue to just fast forward "linus" head without touching the working tree. Come to think of it, it may be cleaner to simply forbid fast-forward fetching into the current repository (whether it is "git fetch" or "git pull"). At least in your workflow you do not do that ever anyway. Johannes, what do you think, as the original advocate of "push in reverse"? - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] Fix pulling into the same branch.
>I am tempted to move this logic to "git fetch" instead, because >it has the same issue. Tony's "linus" branch example has been >updated to do a "git fetch" instead of "git pull" from the >earlier description in his howto, but if he happens to be on the >"linus" branch, he would still have this same problem. I don't spend much time on the linus branch (just to build an updated cscope database, etc.). I never want to check anything in on that branch [sometime I should figure out how use the "hooks" to keep me from shooting myself in the foot here]. >In the meantime, warning the user about the issue and suggesting >how to do the fast-forwarding of the working tree himself in the >warning message might be the safest and the most sensible thing >to do. Yes please ... a big fat warning with coloured flashing lights and explosions from the sound card. -Tony - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fix pulling into the same branch.
Johannes Schindelin <[EMAIL PROTECTED]> writes: > I like it. As Linus stated, the index originally had a different role from > what it has now, so it really should be an internal git thing, i.e. the > git user should not expect the index not to change when pulling. Actually the issue and the way patch addresses it is not limited to the index file. The problem is that the relashionship between your working tree and the $GIT_DIR/HEAD commit changes unexpectedly (from the POV of the working tree) when the ref being updated by the "push in reverse" machinery happens to be the head of the branch you are currently on. The working tree is supposed to be based on $GIT_DIR/HEAD, but after the "push in reverse". This fix is about fast forwarding the working tree, including the checked out files on the filesystem, to the updated head when it happens. I am tempted to move this logic to "git fetch" instead, because it has the same issue. Tony's "linus" branch example has been updated to do a "git fetch" instead of "git pull" from the earlier description in his howto, but if he happens to be on the "linus" branch, he would still have this same problem. Of course, doing this in "git fetch" needs to be done a bit more carefully than in "git pull", because by definition "pull" is a fetch followed by merging into the working tree, implying that the repository has an associated working tree. But "fetch" by itself can be used for a naked repository [*1*], and we should not unconditionally attempt to update the working tree that may not exist. I am planning to use the lack of index file for this detection, but I've seen some people made an rsync copy of their private repository as a whole to publish, so this heuristic may probabaly break. Maybe the lack of "$GIT_DIR/index" and $GIT_DIR not ending with "/.git" and not being ".git"? I am undecided. In the meantime, warning the user about the issue and suggesting how to do the fast-forwarding of the working tree himself in the warning message might be the safest and the most sensible thing to do. [Footnote] *1* Do we want a term in the glossary to mean repositories like linux-2.6.git and git.git that do not have associated working trees? - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fix pulling into the same branch.
Hi, On Thu, 25 Aug 2005, Junio C Hamano wrote: > This patch is to show my current thinking. Please let me know > what you think. I like it. As Linus stated, the index originally had a different role from what it has now, so it really should be an internal git thing, i.e. the git user should not expect the index not to change when pulling. Ciao, Dscho - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
