Re: msysgit: merge, stat

> Johannes Schindelin <Johannes.Schindelin@gmx.de> 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.

> 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.