Re: msysgit: merge, stat

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 13, 2007, 19:54 UTC
Message-ID: <7vzm0vfbw0.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.64.0708131743360.25989@racer.site>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Show 12 quoted lines

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