Johannes Schindelin [off-list ref] writes:
On Sun, 12 Aug 2007, Steffen Prohaska wrote:
quoted
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.
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.
On Aug 13, 2007, at 9:54 PM, Junio C Hamano wrote:
Johannes Schindelin [off-list ref] writes:
quoted
On Sun, 12 Aug 2007, Steffen Prohaska wrote:
quoted
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