msysgit: merge, stat

msysgit: merge, stat

[Steffen Prohaska]

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?

You should basically be able to reproduce the behaviour
by any merge (maybe non-fast-forward, I'm not sure).

	Steffen

Re: msysgit: merge, stat

[Johannes Schindelin]

Hi,

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

There are people who want to change the behaviour, and hide the empty diff 
output, preventing the user from ever knowing why git is so slow.

So just run a "git status" and continue.

Ciao,
Dscho

Re: msysgit: merge, stat

[Steffen Prohaska]

On Aug 13, 2007, at 6:45 PM, Johannes Schindelin wrote:

> Hi,
>
> 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).
>
> There are people who want to change the behaviour, and hide the  
> empty diff
> output, preventing the user from ever knowing why git is so slow.
>
> So just run a "git status" and continue.

Could we add 'git update-index --refresh' after a successful merge,
or would it slow things down. I'm not that much concerned about
the empty diff, but if I start gitk it also finds local changes,
which are not real, and this is always a bit distracting.

	Steffen

Re: msysgit: merge, stat

[Junio C Hamano]

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.

Re: msysgit: merge, stat

[Steffen Prohaska]

On Aug 13, 2007, at 9:54 PM, Junio C Hamano wrote:

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

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

Re: msysgit: merge, stat

[Junio C Hamano]

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

Re: msysgit: merge, stat

[Johannes Schindelin]

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

Re: msysgit: merge, stat

[Steffen Prohaska]

On Aug 14, 2007, at 11:22 AM, Johannes Schindelin wrote:

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

Not really.

If I run

--- snip ---
git init &&
echo 1 > a1 &&
git add a1 &&
git commit -m 1 a1 &&

git checkout -b A master &&
echo A > a1 &&
git commit -m A a1 &&

git checkout -b B master &&
echo B > b1 &&
git add b1 &&
git commit -m B b1 &&

git merge A &&
git diff
--- snip ---

it outputs

diff --git a/a1 b/a1

I planned to pack this into a test script. I started
with the following, which is not yet a full test script.

--- snip ---
#!/bin/sh

test_description='Test is work tree is clean after merge'
. ./test-lib.sh

test_expect_success 'sucessful merge should yield index in sync with  
work tree.' '
echo 1 > a1 &&
git add a1 &&
git commit -m 1 a1 &&

git checkout -b A master &&
echo A > a1 &&
git commit -m A a1 &&

git checkout -b B master &&
echo B > b1 &&
git add b1 &&
git commit -m B b1 &&

git merge A &&
git diff'

test_done
--- snip ---

But if I run the testscript with '-v', git diff doesn't
report anything. I can't tell you why.

	Steffen