Re: msysgit: merge, stat

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 13, 2007, 21:57 UTC
Message-ID: <7vfy2nf67h.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <AAF0E632-AC7D-49E0-A332-96F78EABB1F6@zib.de>

Steffen Prohaska <prohaska@zib.de> writes:

Show 22 quoted lines

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

Johannes, is this something you want me to look at? I do not know how much read-cache.c and other low level routines of Windows version deviated from the mainline.

I do not think we touched this area in any major way recently, but I wouldn't be surprised if refresh_cache_entry() around lstat() on the Windows side looked drastically from the POSIX version.