{"thread":{"id":"9701","subject":"parallel make problem with git","startedAt":"2007-08-30T06:38:10Z","lastAt":"2007-09-03T08:36:32Z","messageCount":26,"participants":["Michael S. Tsirkin","Junio C Hamano","Jeff King","Johannes Schindelin","David Kastrup","Alex Riesen","Steven Grimm","Matthieu Moy"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"51875","messageId":"20070830063810.GD16312@mellanox.co.il","threadId":"9701","inReplyTo":null,"subject":"parallel make problem with git","fromName":"Michael S. Tsirkin","fromEmail":"mst@dev.mellanox.co.il","sentAt":"2007-08-30T06:38:10Z","receivedAt":"2007-08-30T06:38:10Z","isPatch":false,"sender":{"key":"mst@kernel.org","avatar":null},"body":"Try this\n$ git describe\nv1.5.3-rc7\n$make clean\n$make -j 4\n#... builds ok\n$touch revision.c\n$make -j 4\n    CC revision.o\n    AR libgit.a\n    LINK git-fetch-pack\n    LINK git-convert-objects\n    LINK git-hash-object\n    LINK git-index-pack\n    LINK git-local-fetch\n    LINK git-fast-import\n    LINK git-daemon\n    LINK git-mktag\n    LINK git-merge-index\n    LINK git-mktree\n    LINK git-patch-id\n    LINK git-peek-remote\n    LINK git-receive-pack\n    LINK git-send-pack\n    LINK git-shell\n    LINK git-show-index\n    LINK git-ssh-fetch\n    LINK git-ssh-upload\n    LINK git-unpack-file\n    LINK git-update-server-info\n    LINK git-upload-pack\n    LINK git-pack-redundant\n    LINK git-var\n    LINK git-merge-tree\n    LINK git-imap-send\n    LINK git-merge-recursive\n    LINK git-ssh-pull\n    LINK git-ssh-push\n    LINK git-http-fetch\n    LINK git-http-push\n    LINK git\n    LINK test-chmtime\ngcc: test-chmtime.o: No such file or directory\nmake: *** [test-chmtime] Error 1\nmake: *** Waiting for unfinished jobs....\n\nAny ideas?\n\n-- \nMST\n"},{"id":"51876","messageId":"7v7inda5ar.fsf@gitster.siamese.dyndns.org","threadId":"9701","inReplyTo":"20070830063810.GD16312@mellanox.co.il","subject":"Re: parallel make problem with git","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-08-30T06:46:04Z","receivedAt":"2007-08-30T06:46:04Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Michael S. Tsirkin\" <mst@dev.mellanox.co.il> writes:\n\n>     LINK test-chmtime\n> gcc: test-chmtime.o: No such file or directory\n> make: *** [test-chmtime] Error 1\n> make: *** Waiting for unfinished jobs....\n>\n> Any ideas?\n\nSome missing dependencies, apparently.\n"},{"id":"51877","messageId":"20070830065029.GE16312@mellanox.co.il","threadId":"9701","inReplyTo":"7v7inda5ar.fsf@gitster.siamese.dyndns.org","subject":"Re: parallel make problem with git","fromName":"Michael S. Tsirkin","fromEmail":"mst@dev.mellanox.co.il","sentAt":"2007-08-30T06:50:29Z","receivedAt":"2007-08-30T06:50:29Z","isPatch":false,"sender":{"key":"mst@kernel.org","avatar":null},"body":"> Quoting Junio C Hamano <gitster@pobox.com>:\n> Subject: Re: parallel make problem with git\n> \n> \"Michael S. Tsirkin\" <mst@dev.mellanox.co.il> writes:\n> \n> >     LINK test-chmtime\n> > gcc: test-chmtime.o: No such file or directory\n> > make: *** [test-chmtime] Error 1\n> > make: *** Waiting for unfinished jobs....\n> >\n> > Any ideas?\n> \n> Some missing dependencies, apparently.\n\nYes, I guessed as much :)\n\n-- \nMST\n"},{"id":"51880","messageId":"20070830072748.GF16312@mellanox.co.il","threadId":"9701","inReplyTo":"7v7inda5ar.fsf@gitster.siamese.dyndns.org","subject":"[PATCH] fix parallel make problem","fromName":"Michael S. Tsirkin","fromEmail":"mst@dev.mellanox.co.il","sentAt":"2007-08-30T07:27:48Z","receivedAt":"2007-08-30T07:27:48Z","isPatch":true,"sender":{"key":"mst@kernel.org","avatar":null},"body":"There seems to be a bug in parallel build with GNU Make 3.81beta4\nwhich ships with Ubuntu Dapper:\n$touch revision.c\n$make -j 4\nfails with\n\tLINK test-chmtime\n\tgcc: test-chmtime.o: No such file or directory\n\tmake: *** [test-chmtime] Error 1\n\nEven though test-chmtime depends on test-chmtime.o\nWork around this by building test-* executables directly\nfrom the appropriate .c file.\n\nSigned-off-by: Michael S. Tsirkin <mst@dev.mellanox.co.il>\n\n---\n> Quoting Junio C Hamano <gitster@pobox.com>:\n> Subject: Re: parallel make problem with git\n> \n> \"Michael S. Tsirkin\" <mst@dev.mellanox.co.il> writes:\n> \n> >     LINK test-chmtime\n> > gcc: test-chmtime.o: No such file or directory\n> > make: *** [test-chmtime] Error 1\n> > make: *** Waiting for unfinished jobs....\n> >\n> > Any ideas?\n> \n> Some missing dependencies, apparently.\n\nLooks more like bug in make, to me: test-chmtime.o should have been\nbuilt by implicit rule, but isn't.\n\n> make --version\nGNU Make 3.81beta4\n\nThe following patch helps by building the test directly from .c file:\n\ndiff --git a/Makefile b/Makefile\nindex 4eb4637..d6b38b5 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -969,8 +969,8 @@ test-date$X: date.o ctype.o\n \n test-delta$X: diff-delta.o patch-delta.o\n \n-test-%$X: test-%.o $(GITLIBS)\n-\t$(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) $(LIBS)\n+test-%$X: test-%.c $(GITLIBS) GIT-CFLAGS\n+\t$(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.c,$^) $(LIBS)\n \n check-sha1:: test-sha1$X\n \t./test-sha1.sh\n\n-- \nMST\n"},{"id":"51974","messageId":"7vmyw85uml.fsf@gitster.siamese.dyndns.org","threadId":"9701","inReplyTo":"20070830072748.GF16312@mellanox.co.il","subject":"Re: [PATCH] fix parallel make problem","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-08-31T02:02:26Z","receivedAt":"2007-08-31T02:02:26Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"How about this as a replacement?  I notice that after a\nsuccessful build all the test-*.o files are removed by make, and\nsomehow make seems to believe it is Ok not to recreate them.\n\n---\n Makefile |    2 ++\n 1 files changed, 2 insertions(+), 0 deletions(-)\n\ndiff --git a/Makefile b/Makefile\nindex 4eb4637..51af531 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -969,6 +969,8 @@ test-date$X: date.o ctype.o\n \n test-delta$X: diff-delta.o patch-delta.o\n \n+.PRECIOUS: $(patsubst test-%$X,test-%.o,$(TEST_PROGRAMS))\n+\n test-%$X: test-%.o $(GITLIBS)\n \t$(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) $(LIBS)\n \nWarning: 1 path touched but unmodified. Consider running git-status.\n"},{"id":"51999","messageId":"20070831080651.GA17637@mellanox.co.il","threadId":"9701","inReplyTo":"7vmyw85uml.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] fix parallel make problem","fromName":"Michael S. Tsirkin","fromEmail":"mst@dev.mellanox.co.il","sentAt":"2007-08-31T08:06:51Z","receivedAt":"2007-08-31T08:06:51Z","isPatch":true,"sender":{"key":"mst@kernel.org","avatar":null},"body":"> Quoting Junio C Hamano <gitster@pobox.com>:\n> Subject: Re: [PATCH] fix parallel make problem\n> \n> How about this as a replacement?  I notice that after a\n> successful build all the test-*.o files are removed by make, and\n> somehow make seems to believe it is Ok not to recreate them.\n\nYea. this works for me.\n\n> ---\n>  Makefile |    2 ++\n>  1 files changed, 2 insertions(+), 0 deletions(-)\n> \n> diff --git a/Makefile b/Makefile\n> index 4eb4637..51af531 100644\n> --- a/Makefile\n> +++ b/Makefile\n> @@ -969,6 +969,8 @@ test-date$X: date.o ctype.o\n>  \n>  test-delta$X: diff-delta.o patch-delta.o\n>  \n> +.PRECIOUS: $(patsubst test-%$X,test-%.o,$(TEST_PROGRAMS))\n> +\n>  test-%$X: test-%.o $(GITLIBS)\n>  \t$(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) $(LIBS)\n\nAdd a comment here?\n\t\n> Warning: 1 path touched but unmodified. Consider running git-status.\n\nBTW, shouldn't the warning go to standard error?\n\n-- \nMST\n"},{"id":"52000","messageId":"7vabs82kcq.fsf@gitster.siamese.dyndns.org","threadId":"9701","inReplyTo":"20070831080651.GA17637@mellanox.co.il","subject":"Re: [PATCH] fix parallel make problem","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-08-31T08:12:37Z","receivedAt":"2007-08-31T08:12:37Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Michael S. Tsirkin\" <mst@dev.mellanox.co.il> writes:\n\n>> +.PRECIOUS: $(patsubst test-%$X,test-%.o,$(TEST_PROGRAMS))\n>> +\n>>  test-%$X: test-%.o $(GITLIBS)\n>>  \t$(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) $(LIBS)\n>\n> Add a comment here?\n\nI did not see a particular need for that.  What would you say\nthere?\n\n>> Warning: 1 path touched but unmodified. Consider running git-status.\n>\n> BTW, shouldn't the warning go to standard error?\n\nNo, usually you are under PAGER, so we need to send this to\nstdout.  We do this only when we are generating textual diff\nwhich will be consumed by patch or git-apply.  They both know\nhow to ignore such a non patch material.\n"},{"id":"52001","messageId":"20070831081517.GB17637@mellanox.co.il","threadId":"9701","inReplyTo":"7vabs82kcq.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] fix parallel make problem","fromName":"Michael S. Tsirkin","fromEmail":"mst@dev.mellanox.co.il","sentAt":"2007-08-31T08:15:17Z","receivedAt":"2007-08-31T08:15:17Z","isPatch":true,"sender":{"key":"mst@kernel.org","avatar":null},"body":"> Quoting Junio C Hamano <gitster@pobox.com>:\n> Subject: Re: [PATCH] fix parallel make problem\n> \n> \"Michael S. Tsirkin\" <mst@dev.mellanox.co.il> writes:\n> \n> >> +.PRECIOUS: $(patsubst test-%$X,test-%.o,$(TEST_PROGRAMS))\n> >> +\n> >>  test-%$X: test-%.o $(GITLIBS)\n> >>  \t$(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) $(LIBS)\n> >\n> > Add a comment here?\n> \n> I did not see a particular need for that.  What would you say\n> there?\n\nThat it's a work-around for make bug.\n\n> >> Warning: 1 path touched but unmodified. Consider running git-status.\n> >\n> > BTW, shouldn't the warning go to standard error?\n> \n> No, usually you are under PAGER, so we need to send this to\n> stdout.  We do this only when we are generating textual diff\n> which will be consumed by patch or git-apply.  They both know\n> how to ignore such a non patch material.\n\nSo how did this end up in your mail?\n\n-- \nMST\n"},{"id":"52006","messageId":"7v4pig2j91.fsf@gitster.siamese.dyndns.org","threadId":"9701","inReplyTo":"20070831081517.GB17637@mellanox.co.il","subject":"Re: [PATCH] fix parallel make problem","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-08-31T08:36:26Z","receivedAt":"2007-08-31T08:36:26Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Michael S. Tsirkin\" <mst@dev.mellanox.co.il> writes:\n\n>> Quoting Junio C Hamano <gitster@pobox.com>:\n>> Subject: Re: [PATCH] fix parallel make problem\n>> \n>> \"Michael S. Tsirkin\" <mst@dev.mellanox.co.il> writes:\n>> \n>> >> +.PRECIOUS: $(patsubst test-%$X,test-%.o,$(TEST_PROGRAMS))\n>> >> +\n>> >>  test-%$X: test-%.o $(GITLIBS)\n>> >>  \t$(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) $(LIBS)\n>> >\n>> > Add a comment here?\n>> \n>> I did not see a particular need for that.  What would you say\n>> there?\n>\n> That it's a work-around for make bug.\n\nI would agree it is a make bug to barf like what we saw.  Even\nthough we allowed it to treat test-%.o files as intermediate\nproducts and allowed them to be removed, it is not a good excuse\nfor make to forget rebuilding them.\n\nBut I also happen to think not marking test-%.o as precious was\na bug on our side.  We would want to keep the build by-product\nto avoid recompilation, don't we?  And this additional line is\nprimarily about fixing that bug, which works the bug around as a\nside effect.\n\n> So how did this end up in your mail?\n\nBecause it is not a format-patch output.\n\nI often run \"git diff --stat -p HEAD\" from inside MUA in order\nto get the patch from my work tree, write a proposed commit\nmessage, and then reset the change away without committing after\nsending that message (yes I do not need \"git stash\" --- gmane\nand vger are my stashes, Mwhhhaaaa).\n"},{"id":"52043","messageId":"20070831152120.GC17637@mellanox.co.il","threadId":"9701","inReplyTo":"7v4pig2j91.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] fix parallel make problem","fromName":"Michael S. Tsirkin","fromEmail":"mst@dev.mellanox.co.il","sentAt":"2007-08-31T15:21:20Z","receivedAt":"2007-08-31T15:21:20Z","isPatch":true,"sender":{"key":"mst@kernel.org","avatar":null},"body":"> > So how did this end up in your mail?\n> \n> Because it is not a format-patch output.\n> \n> I often run \"git diff --stat -p HEAD\" from inside MUA in order\n> to get the patch from my work tree, write a proposed commit\n> message, and then reset the change away without committing after\n> sending that message (yes I do not need \"git stash\" --- gmane\n> and vger are my stashes, Mwhhhaaaa).\n\nSo maybe we can suppress the warning when the output is not a tty?\n\n\n-- \nMST\n"},{"id":"52046","messageId":"7vr6lj1zg3.fsf@gitster.siamese.dyndns.org","threadId":"9701","inReplyTo":"20070831152120.GC17637@mellanox.co.il","subject":"Re: [PATCH] fix parallel make problem","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-08-31T15:44:12Z","receivedAt":"2007-08-31T15:44:12Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Michael S. Tsirkin\" <mst@dev.mellanox.co.il> writes:\n\n>> > So how did this end up in your mail?\n>> \n>> Because it is not a format-patch output.\n>> \n>> I often run \"git diff --stat -p HEAD\" from inside MUA in order\n>> to get the patch from my work tree, write a proposed commit\n>> message, and then reset the change away without committing after\n>> sending that message (yes I do not need \"git stash\" --- gmane\n>> and vger are my stashes, Mwhhhaaaa).\n>\n> So maybe we can suppress the warning when the output is not a tty?\n\nWhat's your point?\n\nI did not even want to apply that \"empty diff --git removal\"\npatch.  I certainly do _NOT_ want to suppress that replacement\nwarning anywhere.\n\nYou are seriously tempting me to revert the commit\nfb13227e089f22dc31a3b1624559153821056848 (git-diff: squelch\n\"empty\" diffs)...\n"},{"id":"52047","messageId":"20070831160043.GA1973@mellanox.co.il","threadId":"9701","inReplyTo":"7vr6lj1zg3.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] fix parallel make problem","fromName":"Michael S. Tsirkin","fromEmail":"mst@dev.mellanox.co.il","sentAt":"2007-08-31T16:00:43Z","receivedAt":"2007-08-31T16:00:43Z","isPatch":true,"sender":{"key":"mst@kernel.org","avatar":null},"body":"> Quoting Junio C Hamano <gitster@pobox.com>:\n> Subject: Re: [PATCH] fix parallel make problem\n> \n> \"Michael S. Tsirkin\" <mst@dev.mellanox.co.il> writes:\n> \n> >> > So how did this end up in your mail?\n> >> \n> >> Because it is not a format-patch output.\n> >> \n> >> I often run \"git diff --stat -p HEAD\" from inside MUA in order\n> >> to get the patch from my work tree, write a proposed commit\n> >> message, and then reset the change away without committing after\n> >> sending that message (yes I do not need \"git stash\" --- gmane\n> >> and vger are my stashes, Mwhhhaaaa).\n> >\n> > So maybe we can suppress the warning when the output is not a tty?\n> \n> What's your point?\n\nWell, git diff currently says \"consider running git-status\", and one\nwanders why doesn't it just go ahead and run git status instead\nof asking the user to do it.\n\n\n\n-- \nMST\n"},{"id":"52048","messageId":"7vmyw71yn5.fsf@gitster.siamese.dyndns.org","threadId":"9701","inReplyTo":"7vr6lj1zg3.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] fix parallel make problem","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-08-31T16:01:34Z","receivedAt":"2007-08-31T16:01:34Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> \"Michael S. Tsirkin\" <mst@dev.mellanox.co.il> writes:\n> ...\n>> So maybe we can suppress the warning when the output is not a tty?\n>\n> What's your point?\n>\n> I did not even want to apply that \"empty diff --git removal\"\n> patch.  I certainly do _NOT_ want to suppress that replacement\n> warning anywhere.\n>\n> You are seriously tempting me to revert the commit\n> fb13227e089f22dc31a3b1624559153821056848 (git-diff: squelch\n> \"empty\" diffs)...\n\nThis probably needs clarification.\n\nThat warning came because I was experimenting your reproduction\nrecipe of touching revision.c before building.  In earlier git,\nit would have shown \"diff --git a/revision.c b/revision.c\"\nwithout any actual diff text to remind me of that fact, and I\nwould have liked it better than the current \"warning at the end\"\nbehaviour for this particular case.  It was a reminder that my\nrecollection of what I did (and what my understanding of what\nthe state of my work tree is) matches the reality, but the new\n\"squelched\" behaviour lost that value.\n\nWith the older git, whenever I sent out such a \"this is how you\nwould do it\" patch without committing [*1*], I removed those\n\"expected to be empty\" diffs by hand after making a mental note\nthat these were to be expected and my understanding of where I\nam matches reality.  It was a good thing.\n\nThe new \"single warning at the end\" was deliberately done to\nreduce the \"clutter\" (which, this exchange is reminding me was\nnot clutter at all but valuable information) as a response to\nrequests from some people on the list, but because it was made\nmuch less visible, it made me to miss it.\n\nHaving said that, I am _not_ going to revert that change at this\nlate in the game, but I am really tempted to add an option and a\nconfiguration variable to revive the original behaviour (and of\ncourse I'd set that configuration variable in _my_ repository).\n\n\n[Footnote]\n\n*1* Most of the patches I send out to the list are done that\nway; I do \"commit then send patch\" much less often than \"edit,\ntest, send 'diff HEAD' to the list and reset, intending to later\n\"am\" it from the list if it is accepted favourably on the list\".\n"},{"id":"52049","messageId":"20070831160335.GA17761@coredump.intra.peff.net","threadId":"9701","inReplyTo":"7vr6lj1zg3.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] fix parallel make problem","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-08-31T16:03:35Z","receivedAt":"2007-08-31T16:03:35Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Aug 31, 2007 at 08:44:12AM -0700, Junio C Hamano wrote:\n\n> I did not even want to apply that \"empty diff --git removal\"\n> patch.  I certainly do _NOT_ want to suppress that replacement\n> warning anywhere.\n> \n> You are seriously tempting me to revert the commit\n> fb13227e089f22dc31a3b1624559153821056848 (git-diff: squelch\n> \"empty\" diffs)...\n\nFWIW, I find the new message terribly ugly compared to the old behavior.\nThere have been many output changes that I didn't like at first, but for\nwhich I held my tongue and eventually grew to like when they became more\nfamiliar (e.g., the 'subject' line after git-commit).\n\nBut I just can't seem to find this one anything but ugly; everytime I\nsee it, I involuntarily cringe. Perhaps because it really looks like an\nerror message that accidentally got stuck in the diff output through\nincompetent redirection of stdout/stderr.\n\nI say this not to start a flame war (which is perhaps inevitable), but I\njust wonder if others feel the same, now that they have had a chance to\nget used to it.\n\n-Peff\n"},{"id":"52051","messageId":"Pine.LNX.4.64.0708311711210.28586@racer.site","threadId":"9701","inReplyTo":"20070831160043.GA1973@mellanox.co.il","subject":"Re: [PATCH] fix parallel make problem","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-08-31T16:11:43Z","receivedAt":"2007-08-31T16:11:43Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 31 Aug 2007, Michael S. Tsirkin wrote:\n\n> > Quoting Junio C Hamano <gitster@pobox.com>:\n> > Subject: Re: [PATCH] fix parallel make problem\n> > \n> > \"Michael S. Tsirkin\" <mst@dev.mellanox.co.il> writes:\n> > \n> > >> > So how did this end up in your mail?\n> > >> \n> > >> Because it is not a format-patch output.\n> > >> \n> > >> I often run \"git diff --stat -p HEAD\" from inside MUA in order\n> > >> to get the patch from my work tree, write a proposed commit\n> > >> message, and then reset the change away without committing after\n> > >> sending that message (yes I do not need \"git stash\" --- gmane\n> > >> and vger are my stashes, Mwhhhaaaa).\n> > >\n> > > So maybe we can suppress the warning when the output is not a tty?\n> > \n> > What's your point?\n> \n> Well, git diff currently says \"consider running git-status\", and one\n> wanders why doesn't it just go ahead and run git status instead\n> of asking the user to do it.\n\nI knew why I was opposed to that change.  But others shouted louder, I \nguess.\n\nCiao,\nDscho\n"},{"id":"52072","messageId":"7vtzqfzcll.fsf_-_@gitster.siamese.dyndns.org","threadId":"9701","inReplyTo":"20070831160335.GA17761@coredump.intra.peff.net","subject":"[PATCH] diff: resurrect the traditional empty \"diff --git\" behaviour","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-08-31T20:13:42Z","receivedAt":"2007-08-31T20:13:42Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"The \"Consier running git-status\" warning message we experimented\nduring the 1.5.3 cycle turns out to be a bad idea.  It robbed\ncache-dirty information from people who valued it, while still\nasking users to run \"update-index --refresh\".  It was hoped that\nthe new behaviour would at least have some educational value,\nbut not showing the cache-dirty paths like before means the user\nwould not even know easily which paths are cache-dirty.\n\nThis commit reinstates the traditional behaviour as the default,\nbut with a twist.\n\nIf you set diff.autorefreshindex configuration variable, it\nsquelches the empty \"diff --git\" output, and at the end of the\ncommand, it automatically runs \"update-index --refresh\" without\neven bothering the user.  In other words, with the configuration\nvariable set, people who do not care about the cache-dirtyness\ndo not even have to see the warning.\n\nSigned-off-by: Junio C Hamano <gitster@pobox.com>\n---\n\n Jeff King <peff@peff.net> writes:\n\n > FWIW, I find the new message terribly ugly compared to the old behavior.\n > There have been many output changes that I didn't like at first, but for\n > which I held my tongue and eventually grew to like when they became more\n > familiar (e.g., the 'subject' line after git-commit).\n >\n > But I just can't seem to find this one anything but ugly; everytime I\n > see it, I involuntarily cringe. Perhaps because it really looks like an\n > error message that accidentally got stuck in the diff output through\n > incompetent redirection of stdout/stderr.\n >\n > I say this not to start a flame war (which is perhaps inevitable), but I\n > just wonder if others feel the same, now that they have had a chance to\n > get used to it.\n\n Same here.  This patch saw only very light testing, but I\n personally think is a sane thing to do before 1.5.3 final.\n\n builtin-diff.c |   31 ++++++++++++++++++++++++++-----\n cache.h        |    3 +++\n diff.c         |    5 +++++\n 3 files changed, 34 insertions(+), 5 deletions(-)\n\ndiff --git a/builtin-diff.c b/builtin-diff.c\nindex 6ed7b68..4ffbbad 100644\n--- a/builtin-diff.c\n+++ b/builtin-diff.c\n@@ -188,6 +188,30 @@ void add_head(struct rev_info *revs)\n \tadd_pending_object(revs, obj, \"HEAD\");\n }\n \n+static void refresh_index_quietly(void)\n+{\n+\tstruct lock_file *lock_file;\n+\tint fd;\n+\n+\tlock_file = xcalloc(1, sizeof(struct lock_file));\n+\tfd = hold_locked_index(lock_file, 0);\n+\tif (fd < 0)\n+\t\treturn;\n+\tdiscard_cache();\n+\tread_cache();\n+\trefresh_cache(REFRESH_QUIET|REFRESH_UNMERGED);\n+\tif (active_cache_changed) {\n+\t\tif (write_cache(fd, active_cache, active_nr) ||\n+\t\t    close(fd) ||\n+\t\t    commit_locked_index(lock_file))\n+\t\t\t; /*\n+\t\t\t   * silently ignore it -- we haven't mucked\n+\t\t\t   * with the real index.\n+\t\t\t   */\n+\t}\n+\trollback_lock_file(lock_file);\n+}\n+\n int cmd_diff(int argc, const char **argv, const char *prefix)\n {\n \tint i;\n@@ -222,7 +246,7 @@ int cmd_diff(int argc, const char **argv, const char *prefix)\n \tprefix = setup_git_directory_gently(&nongit);\n \tgit_config(git_diff_ui_config);\n \tinit_revisions(&rev, prefix);\n-\trev.diffopt.skip_stat_unmatch = 1;\n+\trev.diffopt.skip_stat_unmatch = !!diff_auto_refresh_index;\n \n \tif (!setup_diff_no_index(&rev, argc, argv, nongit, prefix))\n \t\targc = 0;\n@@ -348,9 +372,6 @@ int cmd_diff(int argc, const char **argv, const char *prefix)\n \n \tif ((rev.diffopt.output_format & DIFF_FORMAT_PATCH)\n \t    && (1 < rev.diffopt.skip_stat_unmatch))\n-\t\tprintf(\"Warning: %d path%s touched but unmodified. \"\n-\t\t       \"Consider running git-status.\\n\",\n-\t\t       rev.diffopt.skip_stat_unmatch - 1,\n-\t\t       rev.diffopt.skip_stat_unmatch == 2 ? \"\" : \"s\");\n+\t\trefresh_index_quietly();\n \treturn result;\n }\ndiff --git a/cache.h b/cache.h\nindex c7e00e7..70abbd5 100644\n--- a/cache.h\n+++ b/cache.h\n@@ -594,6 +594,9 @@ extern char *convert_to_git(const char *path, const char *src, unsigned long *si\n extern char *convert_to_working_tree(const char *path, const char *src, unsigned long *sizep);\n extern void *convert_sha1_file(const char *path, const unsigned char *sha1, unsigned int mode, enum object_type *type, unsigned long *size);\n \n+/* diff.c */\n+extern int diff_auto_refresh_index;\n+\n /* match-trees.c */\n void shift_tree(const unsigned char *, const unsigned char *, unsigned char *, int);\n \ndiff --git a/diff.c b/diff.c\nindex a7e7671..75d95da 100644\n--- a/diff.c\n+++ b/diff.c\n@@ -19,6 +19,7 @@\n static int diff_detect_rename_default;\n static int diff_rename_limit_default = -1;\n static int diff_use_color_default;\n+int diff_auto_refresh_index;\n \n static char diff_colors[][COLOR_MAXLEN] = {\n \t\"\\033[m\",\t/* reset */\n@@ -166,6 +167,10 @@ int git_diff_ui_config(const char *var, const char *value)\n \t\t\tdiff_detect_rename_default = DIFF_DETECT_RENAME;\n \t\treturn 0;\n \t}\n+\tif (!strcmp(var, \"diff.autorefreshindex\")) {\n+\t\tdiff_auto_refresh_index = git_config_bool(var, value);\n+\t\treturn 0;\n+\t}\n \tif (!prefixcmp(var, \"diff.\")) {\n \t\tconst char *ep = strrchr(var, '.');\n \n"},{"id":"52074","messageId":"20070831203250.GA19340@coredump.intra.peff.net","threadId":"9701","inReplyTo":"7vtzqfzcll.fsf_-_@gitster.siamese.dyndns.org","subject":"Re: [PATCH] diff: resurrect the traditional empty \"diff --git\" behaviour","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-08-31T20:32:50Z","receivedAt":"2007-08-31T20:32:50Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Aug 31, 2007 at 01:13:42PM -0700, Junio C Hamano wrote:\n\n> If you set diff.autorefreshindex configuration variable, it\n> squelches the empty \"diff --git\" output, and at the end of the\n> command, it automatically runs \"update-index --refresh\" without\n> even bothering the user.  In other words, with the configuration\n> variable set, people who do not care about the cache-dirtyness\n> do not even have to see the warning.\n\nNice. This is much more sane behavior, IMHO, and I think it should make\neveryone happy.\n\n>  Same here.  This patch saw only very light testing, but I\n>  personally think is a sane thing to do before 1.5.3 final.\n\nPasses my light testing as well, but I have a feeling we just tested the\nsame things...;)\n\nOne question on the implementation (and remember that I am somewhat\nignorant of the structure of this part of the code, so the answer may be\n\"it's too ugly\"): is there a good reason to refresh _after_ the diff? It\nseems like when we are looking through the working tree and index the\nfirst time, we notice that the stat information doesn't match; why can't\nwe update it then? That would save an extra working tree traversal.\n\n-Peff\n"},{"id":"52076","messageId":"Pine.LNX.4.64.0708312154530.28586@racer.site","threadId":"9701","inReplyTo":"20070831203250.GA19340@coredump.intra.peff.net","subject":"Re: [PATCH] diff: resurrect the traditional empty \"diff --git\" behaviour","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-08-31T20:57:29Z","receivedAt":"2007-08-31T20:57:29Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 31 Aug 2007, Jeff King wrote:\n\n> On Fri, Aug 31, 2007 at 01:13:42PM -0700, Junio C Hamano wrote:\n> \n> > If you set diff.autorefreshindex configuration variable, it\n> > squelches the empty \"diff --git\" output, and at the end of the\n> > command, it automatically runs \"update-index --refresh\" without\n> > even bothering the user.  In other words, with the configuration\n> > variable set, people who do not care about the cache-dirtyness\n> > do not even have to see the warning.\n> \n> Nice. This is much more sane behavior, IMHO, and I think it should make \n> everyone happy.\n\nI could even imagine that this will eventually become the standard \nbehaviour.\n\n> >  Same here.  This patch saw only very light testing, but I\n> >  personally think is a sane thing to do before 1.5.3 final.\n> \n> Passes my light testing as well, but I have a feeling we just tested the\n> same things...;)\n> \n> One question on the implementation (and remember that I am somewhat\n> ignorant of the structure of this part of the code, so the answer may be\n> \"it's too ugly\"): is there a good reason to refresh _after_ the diff?\n\nWe do not need to do it always.  After the diff, we know if the index \nneeds refreshing.  Before, we don't.\n\n> It seems like when we are looking through the working tree and index the \n> first time, we notice that the stat information doesn't match; why can't \n> we update it then? That would save an extra working tree traversal.\n\nBut that would be intrusive in the diff machinery IMHO.  It should stay as \nread-only as possible.\n\nBTW I was a little concerned that the locking would fail in a read-only \nsetup, and that git would die(), but that has been taken care of, so I \nhave no objections left.\n\nThanks, Junio.\n\nCiao,\nDscho\n"},{"id":"52084","messageId":"7vhcmfxv4n.fsf@gitster.siamese.dyndns.org","threadId":"9701","inReplyTo":"Pine.LNX.4.64.0708312154530.28586@racer.site","subject":"Re: [PATCH] diff: resurrect the traditional empty \"diff --git\" behaviour","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-08-31T21:16:24Z","receivedAt":"2007-08-31T21:16:24Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n> On Fri, 31 Aug 2007, Jeff King wrote:\n>\n>> On Fri, Aug 31, 2007 at 01:13:42PM -0700, Junio C Hamano wrote:\n>> \n>> > If you set diff.autorefreshindex configuration variable, it\n>> > squelches the empty \"diff --git\" output, and at the end of the\n>> > command, it automatically runs \"update-index --refresh\" without\n>> > even bothering the user.  In other words, with the configuration\n>> > variable set, people who do not care about the cache-dirtyness\n>> > do not even have to see the warning.\n>> \n>> Nice. This is much more sane behavior, IMHO, and I think it should make \n>> everyone happy.\n>\n> I could even imagine that this will eventually become the standard \n> behaviour.\n\nYou sound as if you _like_ that behaviour...\n"},{"id":"52085","messageId":"85lkbrbdv2.fsf@lola.goethe.zz","threadId":"9701","inReplyTo":"Pine.LNX.4.64.0708312154530.28586@racer.site","subject":"Re: [PATCH] diff: resurrect the traditional empty \"diff --git\" behaviour","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-08-31T21:20:17Z","receivedAt":"2007-08-31T21:20:17Z","isPatch":true,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n> On Fri, 31 Aug 2007, Jeff King wrote:\n>\n>> On Fri, Aug 31, 2007 at 01:13:42PM -0700, Junio C Hamano wrote:\n>> \n>> > If you set diff.autorefreshindex configuration variable, it\n>> > squelches the empty \"diff --git\" output, and at the end of the\n>> > command, it automatically runs \"update-index --refresh\" without\n>> > even bothering the user.  In other words, with the configuration\n>> > variable set, people who do not care about the cache-dirtyness\n>> > do not even have to see the warning.\n>> \n>> Nice. This is much more sane behavior, IMHO, and I think it should make \n>> everyone happy.\n>\n> I could even imagine that this will eventually become the standard \n> behaviour.\n>\n>> >  Same here.  This patch saw only very light testing, but I\n>> >  personally think is a sane thing to do before 1.5.3 final.\n>> \n>> Passes my light testing as well, but I have a feeling we just tested the\n>> same things...;)\n>> \n>> One question on the implementation (and remember that I am somewhat\n>> ignorant of the structure of this part of the code, so the answer may be\n>> \"it's too ugly\"): is there a good reason to refresh _after_ the diff?\n>\n> We do not need to do it always.  After the diff, we know if the\n> index needs refreshing.  Before, we don't.\n\nHm.  At the moment where it is first noticed, it should be still\npossible to start a refresh.  Is there a particular gain to be\nexpected?  One thing I could think of is that when using a pager, the\ndiff might often die of SIGPIPE before being able to refresh.\n\n>> It seems like when we are looking through the working tree and\n>> index the first time, we notice that the stat information doesn't\n>> match; why can't we update it then? That would save an extra\n>> working tree traversal.\n>\n> But that would be intrusive in the diff machinery IMHO.  It should\n> stay as read-only as possible.\n\nHm.  Not sure where the gain is in that, if a refresh is done, anyway.\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"52089","messageId":"Pine.LNX.4.64.0708312229270.28586@racer.site","threadId":"9701","inReplyTo":"7vhcmfxv4n.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] diff: resurrect the traditional empty \"diff --git\" behaviour","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-08-31T21:30:03Z","receivedAt":"2007-08-31T21:30:03Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 31 Aug 2007, Junio C Hamano wrote:\n\n> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n> \n> > On Fri, 31 Aug 2007, Jeff King wrote:\n> >\n> >> On Fri, Aug 31, 2007 at 01:13:42PM -0700, Junio C Hamano wrote:\n> >> \n> >> > If you set diff.autorefreshindex configuration variable, it\n> >> > squelches the empty \"diff --git\" output, and at the end of the\n> >> > command, it automatically runs \"update-index --refresh\" without\n> >> > even bothering the user.  In other words, with the configuration\n> >> > variable set, people who do not care about the cache-dirtyness\n> >> > do not even have to see the warning.\n> >> \n> >> Nice. This is much more sane behavior, IMHO, and I think it should make \n> >> everyone happy.\n> >\n> > I could even imagine that this will eventually become the standard \n> > behaviour.\n> \n> You sound as if you _like_ that behaviour...\n\nHeh.  Almost.  I'd like to believe that these complaints would stop.\n\nCiao,\nDscho\n"},{"id":"52091","messageId":"20070831213237.GA4753@steel.home","threadId":"9701","inReplyTo":"7vtzqfzcll.fsf_-_@gitster.siamese.dyndns.org","subject":"Re: [PATCH] diff: resurrect the traditional empty \"diff --git\" behaviour","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-08-31T21:32:37Z","receivedAt":"2007-08-31T21:32:37Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Junio C Hamano, Fri, Aug 31, 2007 22:13:42 +0200:\n> The \"Consier running git-status\" warning message we experimented\n> during the 1.5.3 cycle turns out to be a bad idea.  It robbed\n> cache-dirty information from people who valued it, while still\n> asking users to run \"update-index --refresh\".  It was hoped that\n> the new behaviour would at least have some educational value,\n> but not showing the cache-dirty paths like before means the user\n> would not even know easily which paths are cache-dirty.\n> \n> This commit reinstates the traditional behaviour as the default,\n> but with a twist.\n> \n> If you set diff.autorefreshindex configuration variable, it\n> squelches the empty \"diff --git\" output, and at the end of the\n> command, it automatically runs \"update-index --refresh\" without\n> even bothering the user.  In other words, with the configuration\n> variable set, people who do not care about the cache-dirtyness\n> do not even have to see the warning.\n\nI like this change.\n\nSo far my attempts to explain that warning to myself always left an\nuneasy feeling of me having tricked myself into believing in its\nusefullness.\n"},{"id":"52100","messageId":"46D89844.8050605@midwinter.com","threadId":"9701","inReplyTo":"7vtzqfzcll.fsf_-_@gitster.siamese.dyndns.org","subject":"Re: [PATCH] diff: resurrect the traditional empty \"diff --git\" behaviour","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2007-08-31T22:37:56Z","receivedAt":"2007-08-31T22:37:56Z","isPatch":true,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"Junio C Hamano wrote:\n> This commit reinstates the traditional behaviour as the default,\n> but with a twist.\n>\n> If you set diff.autorefreshindex configuration variable, it\n> squelches the empty \"diff --git\" output, and at the end of the\n> command, it automatically runs \"update-index --refresh\" without\n> even bothering the user.  In other words, with the configuration\n> variable set, people who do not care about the cache-dirtyness\n> do not even have to see the warning.\n>   \n\nAs the person who submitted the patch you're reversing with this, I \nagree 100% this is the better approach. Having the system self-heal is \nfar preferable to requiring user action.\n\nI would vote for reversing the sense of that config variable, actually: \nmy guess is that most users, especially new ones who won't necessarily \nknow about the config variable, would rather have git just keep itself \nhealthy without user intervention. Having to manually update the index \nis (by virtue of requiring you to run a command that you wouldn't \notherwise need to run) a mode more suited to advanced / experienced \nusers, who are more likely to already be comfortable with the idea of \nflipping config switches. Making the more novice-friendly mode require \nthat you know how to set a particular configuration variable doesn't \nseem right to me.\n\n-Steve\n"},{"id":"52112","messageId":"7vir6vw4x2.fsf@gitster.siamese.dyndns.org","threadId":"9701","inReplyTo":"46D89844.8050605@midwinter.com","subject":"Re: [PATCH] diff: resurrect the traditional empty \"diff --git\" behaviour","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-09-01T01:27:53Z","receivedAt":"2007-09-01T01:27:53Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Steven Grimm <koreth@midwinter.com> writes:\n\n> Junio C Hamano wrote:\n>> This commit reinstates the traditional behaviour as the default,\n>> but with a twist.\n>>\n>> If you set diff.autorefreshindex configuration variable, it\n>> squelches the empty \"diff --git\" output, and at the end of the\n>> command, it automatically runs \"update-index --refresh\" without\n>> even bothering the user.  In other words, with the configuration\n>> variable set, people who do not care about the cache-dirtyness\n>> do not even have to see the warning.\n>\n> As the person who submitted the patch you're reversing with this, I\n> agree 100% this is the better approach. Having the system self-heal is\n> far preferable to requiring user action.\n>\n> I would vote for reversing the sense of that config variable,\n\n(grudgingly...) Ok.\n\nOld timers like myself have been warned on the list that\ndiff output will get quieter, so why not.\n\nThis is on top of the previous one in this thread.\n\n\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex 903610f..cf7617a 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -396,6 +396,16 @@ color.status.<slot>::\n commit.template::\n \tSpecify a file to use as the template for new commit messages.\n \n+diff.autorefreshindex::\n+\tWhen using `git diff` to compare with work tree\n+\tfiles, do not consider stat-only change as changed.\n+\tInstead, silently run `git update-index --refresh` to\n+\tupdate the cached stat information for paths whose\n+\tcontents in the work tree match the contents in the\n+\tindex.  This option defaults to true.  Note that this\n+\taffects only `git diff` Porcelain, and not lower level\n+\t`diff` commands, such as `git diff-files`.\n+\n diff.renameLimit::\n \tThe number of files to consider when performing the copy/rename\n \tdetection; equivalent to the git diff option '-l'.\ndiff --git a/diff.c b/diff.c\nindex 75d95da..0d30d05 100644\n--- a/diff.c\n+++ b/diff.c\n@@ -19,7 +19,7 @@\n static int diff_detect_rename_default;\n static int diff_rename_limit_default = -1;\n static int diff_use_color_default;\n-int diff_auto_refresh_index;\n+int diff_auto_refresh_index = 1;\n \n static char diff_colors[][COLOR_MAXLEN] = {\n \t\"\\033[m\",\t/* reset */\n"},{"id":"52310","messageId":"vpqveasmaqo.fsf@bauges.imag.fr","threadId":"9701","inReplyTo":"7vir6vw4x2.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] diff: resurrect the traditional empty \"diff --git\" behaviour","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2007-09-03T08:09:03Z","receivedAt":"2007-09-03T08:09:03Z","isPatch":true,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"I fully agree with the two patches (that's what I've been arguing for\nhours last time we talked about it, so no big surprise ;-) ).\n\nOne documentation nitpick :\n\nJunio C Hamano <gitster@pobox.com> writes:\n\n> +diff.autorefreshindex::\n> +\tWhen using `git diff` to compare with work tree\n> +\tfiles, do not consider stat-only change as changed.\n> +\tInstead, silently run `git update-index --refresh`\n\nI'd rather avoid talking about plumbing in the documentation of\nporcelain, so I'd say \"silently refreshes the index's stat\ninformation\".\n\nBut I'm arguably wrong on that point, I let you decide.\n\nThanks,\n\n-- \nMatthieu\n"},{"id":"52319","messageId":"7vbqckm9gv.fsf@gitster.siamese.dyndns.org","threadId":"9701","inReplyTo":"vpqveasmaqo.fsf@bauges.imag.fr","subject":"Re: [PATCH] diff: resurrect the traditional empty \"diff --git\" behaviour","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-09-03T08:36:32Z","receivedAt":"2007-09-03T08:36:32Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy <Matthieu.Moy@imag.fr> writes:\n\n> I'd rather avoid talking about plumbing in the documentation of\n> porcelain, so I'd say \"silently refreshes the index's stat\n> information\".\n\nSounds like a much better wording.\n"}]}