Re: msysgit: merge, stat

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi,

On Mon, 13 Aug 2007, Junio C Hamano wrote:

> Steffen Prohaska <prohaska@zib.de> writes:
> 
> >> 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 am reasonably sure that we did not deviate that much in lstat(). And in 
stat() we do not deviate at all; this is provided by mscrt.dll.

Steffen, could you come up with a test script showing the behaviour you 
described?  Then we could test where the problem comes from.

Ciao,
Dscho