{"thread":{"id":"9507","subject":"msysgit: merge, stat","startedAt":"2007-08-12T21:00:59Z","lastAt":"2007-08-14T21:03:54Z","messageCount":8,"participants":["Steffen Prohaska","Johannes Schindelin","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"50596","messageId":"2C573942-DD22-46EC-AE4A-1334450A7C4D@zib.de","threadId":"9507","inReplyTo":null,"subject":"msysgit: merge, stat","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-08-12T21:00:59Z","receivedAt":"2007-08-12T21:00:59Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"After a 'git merge' in msysgit some stat information of the index\ndoesn't match the working tree. Thus 'git diff' looks at files,\nwhich it shouldn't look at. I need to do a\n'git update-index --refresh' before everything's in sync.\n\nIs this a know issue? Do other experience the same?\n\nYou should basically be able to reproduce the behaviour\nby any merge (maybe non-fast-forward, I'm not sure).\n\n\tSteffen\n"},{"id":"50641","messageId":"Pine.LNX.4.64.0708131743360.25989@racer.site","threadId":"9507","inReplyTo":"2C573942-DD22-46EC-AE4A-1334450A7C4D@zib.de","subject":"Re: msysgit: merge, stat","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-08-13T16:45:07Z","receivedAt":"2007-08-13T16:45:07Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 12 Aug 2007, Steffen Prohaska wrote:\n\n> After a 'git merge' in msysgit some stat information of the index\n> doesn't match the working tree. Thus 'git diff' looks at files,\n> which it shouldn't look at. I need to do a\n> 'git update-index --refresh' before everything's in sync.\n> \n> Is this a know issue? Do other experience the same?\n\nYes, it is. The real issue is that the index is out of date, and the full \nspeed of git is not available until a refresh (which you can have with a \n\"git status\", too).\n\nThere are people who want to change the behaviour, and hide the empty diff \noutput, preventing the user from ever knowing why git is so slow.\n\nSo just run a \"git status\" and continue.\n\nCiao,\nDscho\n"},{"id":"50645","messageId":"23ED0751-B872-46E0-A6F5-2C0A72C4EA53@zib.de","threadId":"9507","inReplyTo":"Pine.LNX.4.64.0708131743360.25989@racer.site","subject":"Re: msysgit: merge, stat","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-08-13T17:41:24Z","receivedAt":"2007-08-13T17:41:24Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Aug 13, 2007, at 6:45 PM, Johannes Schindelin wrote:\n\n> Hi,\n>\n> On Sun, 12 Aug 2007, Steffen Prohaska wrote:\n>\n>> After a 'git merge' in msysgit some stat information of the index\n>> doesn't match the working tree. Thus 'git diff' looks at files,\n>> which it shouldn't look at. I need to do a\n>> 'git update-index --refresh' before everything's in sync.\n>>\n>> Is this a know issue? Do other experience the same?\n>\n> Yes, it is. The real issue is that the index is out of date, and \n> the full\n> speed of git is not available until a refresh (which you can have \n> with a\n> \"git status\", too).\n>\n> There are people who want to change the behaviour, and hide the \n> empty diff\n> output, preventing the user from ever knowing why git is so slow.\n>\n> So just run a \"git status\" and continue.\n\nCould we add 'git update-index --refresh' after a successful merge,\nor would it slow things down. I'm not that much concerned about\nthe empty diff, but if I start gitk it also finds local changes,\nwhich are not real, and this is always a bit distracting.\n\n\tSteffen\n"},{"id":"50650","messageId":"7vzm0vfbw0.fsf@assigned-by-dhcp.cox.net","threadId":"9507","inReplyTo":"Pine.LNX.4.64.0708131743360.25989@racer.site","subject":"Re: msysgit: merge, stat","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-08-13T19:54:55Z","receivedAt":"2007-08-13T19:54:55Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> On Sun, 12 Aug 2007, Steffen Prohaska wrote:\n>\n>> After a 'git merge' in msysgit some stat information of the index\n>> doesn't match the working tree. Thus 'git diff' looks at files,\n>> which it shouldn't look at. I need to do a\n>> 'git update-index --refresh' before everything's in sync.\n>> \n>> Is this a know issue? Do other experience the same?\n>\n> Yes, it is. The real issue is that the index is out of date, and the full \n> speed of git is not available until a refresh (which you can have with a \n> \"git status\", too).\n\nWait a minute.\n\nWhat does the above \"After a 'git merge'\" exactly mean? After a\nsuccessful automerge that made a commit, of stopped in the\nmiddle because of conflicts? I am getting an impression that\nSteffen is talking about the former, but if that is the case,\nsomebody is seriously confused.\n\nWhen \"merge-recursive\" with a 3-way file level merge in core\nwrites the result out to the work tree, it uses a cache entry\nthat is stat clean (see merge-recursive.c::make_cache_entry(),\nrefresh option is passed and it calls refresh_cache_entry() to\nobtain the cached stat bits). The traditional \"read-tree -m -u\"\nfollowed by merge-one-file of course runs \"git update-index\"\ninside merge-one-file script and cleanly merged paths should be\nstat clean after a merge.\n"},{"id":"50658","messageId":"AAF0E632-AC7D-49E0-A332-96F78EABB1F6@zib.de","threadId":"9507","inReplyTo":"7vzm0vfbw0.fsf@assigned-by-dhcp.cox.net","subject":"Re: msysgit: merge, stat","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-08-13T21:31:29Z","receivedAt":"2007-08-13T21:31:29Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Aug 13, 2007, at 9:54 PM, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n>\n>> On Sun, 12 Aug 2007, Steffen Prohaska wrote:\n>>\n>>> After a 'git merge' in msysgit some stat information of the index\n>>> doesn't match the working tree. Thus 'git diff' looks at files,\n>>> which it shouldn't look at. I need to do a\n>>> 'git update-index --refresh' before everything's in sync.\n>>>\n>>> Is this a know issue? Do other experience the same?\n>>\n>> Yes, it is. The real issue is that the index is out of date, and \n>> the full\n>> speed of git is not available until a refresh (which you can have \n>> with a\n>> \"git status\", too).\n>\n> Wait a minute.\n>\n> What does the above \"After a 'git merge'\" exactly mean? After a\n> successful automerge that made a commit, of stopped in the\n> middle because of conflicts? I am getting an impression that\n> Steffen is talking about the former, but if that is the case,\n> somebody is seriously confused.\n\nYes. I'm talking about a successful merge that made a commit.\n\n\n> When \"merge-recursive\" with a 3-way file level merge in core\n> writes the result out to the work tree, it uses a cache entry\n> that is stat clean (see merge-recursive.c::make_cache_entry(),\n> refresh option is passed and it calls refresh_cache_entry() to\n> obtain the cached stat bits). The traditional \"read-tree -m -u\"\n> followed by merge-one-file of course runs \"git update-index\"\n> inside merge-one-file script and cleanly merged paths should be\n> stat clean after a merge.\n\nWell, they are not with msysgit. At least not all, or not always.\nI'm not completely sure about the details, but the problem\nhappens frequently, near to always.\n\n\tSteffen\n"},{"id":"50660","messageId":"7vfy2nf67h.fsf@assigned-by-dhcp.cox.net","threadId":"9507","inReplyTo":"AAF0E632-AC7D-49E0-A332-96F78EABB1F6@zib.de","subject":"Re: msysgit: merge, stat","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-08-13T21:57:38Z","receivedAt":"2007-08-13T21:57:38Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Steffen Prohaska writes:\n\n>> Wait a minute.\n>>\n>> What does the above \"After a 'git merge'\" exactly mean? After a\n>> successful automerge that made a commit, of stopped in the\n>> middle because of conflicts? I am getting an impression that\n>> Steffen is talking about the former, but if that is the case,\n>> somebody is seriously confused.\n>\n> Yes. I'm talking about a successful merge that made a commit.\n>\n>> When \"merge-recursive\" with a 3-way file level merge in core\n>> writes the result out to the work tree, it uses a cache entry\n>> that is stat clean (see merge-recursive.c::make_cache_entry(),\n>> refresh option is passed and it calls refresh_cache_entry() to\n>> obtain the cached stat bits). The traditional \"read-tree -m -u\"\n>> followed by merge-one-file of course runs \"git update-index\"\n>> inside merge-one-file script and cleanly merged paths should be\n>> stat clean after a merge.\n>\n> Well, they are not with msysgit. At least not all, or not always.\n> I'm not completely sure about the details, but the problem\n> happens frequently, near to always.\n\nJohannes, is this something you want me to look at? I do not\nknow how much read-cache.c and other low level routines of\nWindows version deviated from the mainline.\n\nI do not think we touched this area in any major way recently,\nbut I wouldn't be surprised if refresh_cache_entry() around\nlstat() on the Windows side looked drastically from the POSIX\nversion.\n"},{"id":"50691","messageId":"Pine.LNX.4.64.0708141013540.25989@racer.site","threadId":"9507","inReplyTo":"7vfy2nf67h.fsf@assigned-by-dhcp.cox.net","subject":"Re: msysgit: merge, stat","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-08-14T09:22:00Z","receivedAt":"2007-08-14T09:22:00Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 13 Aug 2007, Junio C Hamano wrote:\n\n> Steffen Prohaska writes:\n> \n> >> Wait a minute.\n> >>\n> >> What does the above \"After a 'git merge'\" exactly mean? After a\n> >> successful automerge that made a commit, of stopped in the\n> >> middle because of conflicts? I am getting an impression that\n> >> Steffen is talking about the former, but if that is the case,\n> >> somebody is seriously confused.\n> >\n> > Yes. I'm talking about a successful merge that made a commit.\n> >\n> >> When \"merge-recursive\" with a 3-way file level merge in core\n> >> writes the result out to the work tree, it uses a cache entry\n> >> that is stat clean (see merge-recursive.c::make_cache_entry(),\n> >> refresh option is passed and it calls refresh_cache_entry() to\n> >> obtain the cached stat bits). The traditional \"read-tree -m -u\"\n> >> followed by merge-one-file of course runs \"git update-index\"\n> >> inside merge-one-file script and cleanly merged paths should be\n> >> stat clean after a merge.\n> >\n> > Well, they are not with msysgit. At least not all, or not always.\n> > I'm not completely sure about the details, but the problem\n> > happens frequently, near to always.\n> \n> Johannes, is this something you want me to look at? I do not\n> know how much read-cache.c and other low level routines of\n> Windows version deviated from the mainline.\n\nI am reasonably sure that we did not deviate that much in lstat(). And in \nstat() we do not deviate at all; this is provided by mscrt.dll.\n\nSteffen, could you come up with a test script showing the behaviour you \ndescribed? Then we could test where the problem comes from.\n\nCiao,\nDscho\n"},{"id":"50727","messageId":"557AE5F5-E937-4CA8-9280-C33CB640B458@zib.de","threadId":"9507","inReplyTo":"Pine.LNX.4.64.0708141013540.25989@racer.site","subject":"Re: msysgit: merge, stat","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-08-14T21:03:54Z","receivedAt":"2007-08-14T21:03:54Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Aug 14, 2007, at 11:22 AM, Johannes Schindelin wrote:\n\n> Hi,\n>\n> On Mon, 13 Aug 2007, Junio C Hamano wrote:\n>\n>> Steffen Prohaska writes:\n>>\n>>>> Wait a minute.\n>>>>\n>>>> What does the above \"After a 'git merge'\" exactly mean? After a\n>>>> successful automerge that made a commit, of stopped in the\n>>>> middle because of conflicts? I am getting an impression that\n>>>> Steffen is talking about the former, but if that is the case,\n>>>> somebody is seriously confused.\n>>>\n>>> Yes. I'm talking about a successful merge that made a commit.\n>>>\n>>>> When \"merge-recursive\" with a 3-way file level merge in core\n>>>> writes the result out to the work tree, it uses a cache entry\n>>>> that is stat clean (see merge-recursive.c::make_cache_entry(),\n>>>> refresh option is passed and it calls refresh_cache_entry() to\n>>>> obtain the cached stat bits). The traditional \"read-tree -m -u\"\n>>>> followed by merge-one-file of course runs \"git update-index\"\n>>>> inside merge-one-file script and cleanly merged paths should be\n>>>> stat clean after a merge.\n>>>\n>>> Well, they are not with msysgit. At least not all, or not always.\n>>> I'm not completely sure about the details, but the problem\n>>> happens frequently, near to always.\n>>\n>> Johannes, is this something you want me to look at? I do not\n>> know how much read-cache.c and other low level routines of\n>> Windows version deviated from the mainline.\n>\n> I am reasonably sure that we did not deviate that much in lstat(). \n> And in\n> stat() we do not deviate at all; this is provided by mscrt.dll.\n>\n> Steffen, could you come up with a test script showing the behaviour \n> you\n> described? Then we could test where the problem comes from.\n\nNot really.\n\nIf I run\n\n--- snip ---\ngit init &&\necho 1 > a1 &&\ngit add a1 &&\ngit commit -m 1 a1 &&\n\ngit checkout -b A master &&\necho A > a1 &&\ngit commit -m A a1 &&\n\ngit checkout -b B master &&\necho B > b1 &&\ngit add b1 &&\ngit commit -m B b1 &&\n\ngit merge A &&\ngit diff\n--- snip ---\n\nit outputs\n\ndiff --git a/a1 b/a1\n\nI planned to pack this into a test script. I started\nwith the following, which is not yet a full test script.\n\n--- snip ---\n#!/bin/sh\n\ntest_description='Test is work tree is clean after merge'\n. ./test-lib.sh\n\ntest_expect_success 'sucessful merge should yield index in sync with \nwork tree.' '\necho 1 > a1 &&\ngit add a1 &&\ngit commit -m 1 a1 &&\n\ngit checkout -b A master &&\necho A > a1 &&\ngit commit -m A a1 &&\n\ngit checkout -b B master &&\necho B > b1 &&\ngit add b1 &&\ngit commit -m B b1 &&\n\ngit merge A &&\ngit diff'\n\ntest_done\n--- snip ---\n\nBut if I run the testscript with '-v', git diff doesn't\nreport anything. I can't tell you why.\n\n\tSteffen\n"}]}