Steffen ProhaskaAfter 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
Johannes SchindelinRe: msysgit: merge, stat
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
Steffen ProhaskaRe: msysgit: merge, stat
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
Junio C HamanoRe: 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.
Steffen ProhaskaRe: msysgit: merge, stat
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
Junio C HamanoRe: msysgit: merge, stat
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.
Johannes SchindelinRe: msysgit: merge, stat
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
Steffen ProhaskaRe: msysgit: merge, stat
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