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

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.


*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

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at

Reply via email to