On Aug 13, 2007, at 9:54 PM, Junio C Hamano wrote:
Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:
On Sun, 12 Aug 2007, Steffen Prohaska wrote:
After a 'git merge' in msysgit some stat information of the index
doesn't match the working tree. Thus 'git diff' looks at files,
which it shouldn't look at. I need to do a
'git update-index --refresh' before everything's in sync.
Is this a know issue? Do other experience the same?
Yes, it is. The real issue is that the index is out of date, and
the full
speed of git is not available until a refresh (which you can have
with a
"git status", too).
Wait a minute.
What does the above "After a 'git merge'" exactly mean? After a
successful automerge that made a commit, of stopped in the
middle because of conflicts? I am getting an impression that
Steffen is talking about the former, but if that is the case,
somebody is seriously confused.
Yes. I'm talking about a successful merge that made a commit.
When "merge-recursive" with a 3-way file level merge in core
writes the result out to the work tree, it uses a cache entry
that is stat clean (see merge-recursive.c::make_cache_entry(),
refresh option is passed and it calls refresh_cache_entry() to
obtain the cached stat bits). The traditional "read-tree -m -u"
followed by merge-one-file of course runs "git update-index"
inside merge-one-file script and cleanly merged paths should be
stat clean after a merge.
Well, they are not with msysgit. At least not all, or not always.
I'm not completely sure about the details, but the problem
happens frequently, near to always.
Steffen
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
