{"thread":{"id":"9342","subject":"git-diff on touched files: bug or feature?","startedAt":"2007-08-01T16:17:13Z","lastAt":"2007-08-11T20:07:33Z","messageCount":75,"participants":["Matthieu Moy","Junio C Hamano","Alexandre Julliard","Johannes Schindelin","Joel Reed","Jean-François Veillette","Steven Grimm","J. Bruce Fields","Jeff King","Shawn O. Pearce","Matthias Lederhofer","David Kastrup","Linus Torvalds","Jakub Narebski"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"49318","messageId":"vpqwswf8c1i.fsf@bauges.imag.fr","threadId":"9342","inReplyTo":null,"subject":"git-diff on touched files: bug or feature?","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2007-08-01T16:17:13Z","receivedAt":"2007-08-01T16:17:13Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Hi,\n\nWhen a file is \"touched\" (ie. stat information not matching the index,\nbut the content still matching), git-status doesn't report the file as\nmodified (as expected), but git-diff does (with an empty diff):\n\n$ git st\n# On branch master\nnothing to commit (working directory clean)\n$ ls \nbar\n$ touch bar\n$ git diff\ndiff --git a/bar b/bar <--- here ---<\n$ git status\n# On branch master\nnothing to commit (working directory clean)\n$ git diff <--- status updated\n the stat in the index.\n\nIs this intended, or just that the code that reconciles the file and\nthe index has been written for status, but not used in diff?\n\nThanks,\n\n-- \nMatthieu\n"},{"id":"49330","messageId":"7v4pjj5fp6.fsf@assigned-by-dhcp.cox.net","threadId":"9342","inReplyTo":"vpqwswf8c1i.fsf@bauges.imag.fr","subject":"Re: git-diff on touched files: bug or feature?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-08-01T17:26:29Z","receivedAt":"2007-08-01T17:26:29Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy writes:\n\n> $ touch bar\n> $ git diff\n> diff --git a/bar b/bar <--- here ---<\n> $ git status\n> # On branch master\n> nothing to commit (working directory clean)\n> $ git diff <--- status updated\n> the stat in the index.\n>\n> Is this intended,\n\nYes. Very much so, intentionally, from very early days of git.\nThis serves as a reminder to the user that he started editing\nbut changed his mind to end up with the same contents as the\noriginal, until the next \"update-index --refresh\" (which is\ninternally invoked from \"status\").\n\nIf the feature still makes sense in the modern world is a\ndifferent story, but I do find it useful.\n\nNot the made-up \"touch\" example, but often in real life, I\nexplore a solution by first making changes to one part of the\nsystem, realizing a better way is to change the caller of what I\ninitially thought should be changed, edit the file back and\nmodify the caller which is in another file. The former file\nwill show that empty \"header-only\" diff as the reminder of what\nI did.\n\nAfter that, when I reach the point to run \"git status\", because\nI have been reminded, I already know about these \"tried but\ndiscarded\" changes, and I find the fact that the they are forgot\nby that operation very convenient.\n"},{"id":"49337","messageId":"87vebzkrid.fsf@wine.dyndns.org","threadId":"9342","inReplyTo":"7v4pjj5fp6.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-diff on touched files: bug or feature?","fromName":"Alexandre Julliard","fromEmail":"julliard@winehq.org","sentAt":"2007-08-01T19:02:18Z","receivedAt":"2007-08-01T19:02:18Z","isPatch":false,"sender":{"key":"julliard@winehq.org","avatar":null},"body":"Junio C Hamano writes:\n\n> Yes. Very much so, intentionally, from very early days of git.\n> This serves as a reminder to the user that he started editing\n> but changed his mind to end up with the same contents as the\n> original, until the next \"update-index --refresh\" (which is\n> internally invoked from \"status\").\n\nIt would be nice to have a way to refresh a single file though. For\ninstance in vc-git.el the workfile-unchanged-p function currently has\nto rehash the file every time to see if it really changed, because we\ncan't afford to refresh the whole project at that point.\n\n-- \nAlexandre Julliard\njulliard@winehq.org\n"},{"id":"49338","messageId":"7vvebz3wh3.fsf@assigned-by-dhcp.cox.net","threadId":"9342","inReplyTo":"87vebzkrid.fsf@wine.dyndns.org","subject":"Re: git-diff on touched files: bug or feature?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-08-01T19:07:04Z","receivedAt":"2007-08-01T19:07:04Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Alexandre Julliard writes:\n\n> .... For\n> instance in vc-git.el the workfile-unchanged-p function currently has\n> to rehash the file every time to see if it really changed, because we\n> can't afford to refresh the whole project at that point.\n\nMaybe I am missing something. Why can't you \"afford to\"?\n\n\"update-index --refresh\" looks at only the files whose cached\nstat information does indicate there might be chanegs. It does\nnot rehash already up-to-date ones.\n"},{"id":"49340","messageId":"87r6mnkqsj.fsf@wine.dyndns.org","threadId":"9342","inReplyTo":"7vvebz3wh3.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-diff on touched files: bug or feature?","fromName":"Alexandre Julliard","fromEmail":"julliard@winehq.org","sentAt":"2007-08-01T19:17:48Z","receivedAt":"2007-08-01T19:17:48Z","isPatch":false,"sender":{"key":"julliard@winehq.org","avatar":null},"body":"Junio C Hamano writes:\n\n> Alexandre Julliard writes:\n>\n>> .... For\n>> instance in vc-git.el the workfile-unchanged-p function currently has\n>> to rehash the file every time to see if it really changed, because we\n>> can't afford to refresh the whole project at that point.\n>\n> Maybe I am missing something. Why can't you \"afford to\"?\n>\n> \"update-index --refresh\" looks at only the files whose cached\n> stat information does indicate there might be chanegs. It does\n> not rehash already up-to-date ones.\n\nNo, but it goes through the tree and stats every single file. On a\nlarge project that can be slow, especially if you don't have enough\nRAM to keep it all in cache, so it's not something we can do while the\nuser is interacting with a file.\n\n-- \nAlexandre Julliard\njulliard@winehq.org\n"},{"id":"49400","messageId":"vpqhcni47ek.fsf@bauges.imag.fr","threadId":"9342","inReplyTo":"7v4pjj5fp6.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-diff on touched files: bug or feature?","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2007-08-02T09:23:15Z","receivedAt":"2007-08-02T09:23:15Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Junio C Hamano writes:\n\n> Matthieu Moy writes:\n>\n>> $ touch bar\n>> $ git diff\n>> diff --git a/bar b/bar <--- here ---<\n>> $ git status\n>> # On branch master\n>> nothing to commit (working directory clean)\n>> $ git diff <--- status updated\n>> the stat in the index.\n>>\n>> Is this intended,\n>\n> Yes. Very much so, intentionally, from very early days of git.\n> This serves as a reminder to the user that he started editing\n> but changed his mind to end up with the same contents as the\n> original, until the next \"update-index --refresh\" (which is\n> internally invoked from \"status\").\n>\n> If the feature still makes sense in the modern world is a\n> different story, but I do find it useful.\n\nI understand that it can be usefull, but I really don't like having it\nby default (is there a way to deactivate it BTW?):\n\nI've hit this while working on a project, doing a lot of modifications\nthrough scripting (some regexp substitutions and such kinds of\nthings). Then, git-diff shows me pages of \"diff --git ...\", and a few\nrelevant entries in the middle of it. That's very bad from the\nusability point of view (I actually had some ~20 lines diff surrounded\nby 100+ irrelevant lines), and also kills performance: if a script\ntouches a lot of files, I expect the next \"diff\" or \"status\" to be\nslow, but not the second next. Here, diff will be slow until I run\ngit-status again.\n\nAnd I find the \"reminder\" feature very fragile. That means git-status\nis no longer a read-only operation for the user. As a user, I expect\nto be able to run git-status without changing the behavior of\nsubsequent git commands, which is not the case here. That means for\nexample that someone used to running git-diff /before/ git-status will\nget the reminder, while someone used to running git-diff /after/\ngit-status (which I find sensible, get an overview before getting the\ndetails of what you did) won't get it. Note also that this makes a\ndifference between git-status (which updates the stat in the index)\nand git-status -a (which doesn't). That's an implementation detail\nthat shouldn't be exposed to the user.\n\nSince I don't see any mention of this in the man pages for git-diff or\ngit-status (I might have missed it), I wonder how many user actually\never used this as a feature.\n\nI'd be in favor of disabling this by default, and providing a\nconfiguration option and/or a command line option to diff to enable\nit. I can try writting a patch for this if people agree on the\nspecification.\n\n-- \nMatthieu\n"},{"id":"49403","messageId":"Pine.LNX.4.64.0708021050500.14781@racer.site","threadId":"9342","inReplyTo":"vpqhcni47ek.fsf@bauges.imag.fr","subject":"Re: git-diff on touched files: bug or feature?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-08-02T09:51:17Z","receivedAt":"2007-08-02T09:51:17Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 2 Aug 2007, Matthieu Moy wrote:\n\n> Junio C Hamano writes:\n> \n> > Matthieu Moy writes:\n> >\n> >> $ touch bar\n> >> $ git diff\n> >> diff --git a/bar b/bar <--- here ---<\n> >> $ git status\n> >> # On branch master\n> >> nothing to commit (working directory clean)\n> >> $ git diff <--- status updated\n> >> the stat in the index.\n> >>\n> >> Is this intended,\n> >\n> > Yes. Very much so, intentionally, from very early days of git.\n> > This serves as a reminder to the user that he started editing\n> > but changed his mind to end up with the same contents as the\n> > original, until the next \"update-index --refresh\" (which is\n> > internally invoked from \"status\").\n> >\n> > If the feature still makes sense in the modern world is a\n> > different story, but I do find it useful.\n> \n> I understand that it can be usefull, but I really don't like having it\n> by default (is there a way to deactivate it BTW?).\n\nYes. Just call \"git status\" and be done with it.\n\nCiao,\nDscho\n"},{"id":"49404","messageId":"7vd4y6xnw4.fsf@assigned-by-dhcp.cox.net","threadId":"9342","inReplyTo":"vpqhcni47ek.fsf@bauges.imag.fr","subject":"Re: git-diff on touched files: bug or feature?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-08-02T09:54:19Z","receivedAt":"2007-08-02T09:54:19Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy writes:\n\n> I understand that it can be usefull, but I really don't like having it\n> by default (is there a way to deactivate it BTW?):\n\nYou said it yourself below --- run git-status (or update-index --refresh)\nfirst.\n\n> I've hit this while working on a project, doing a lot of modifications\n> through scripting (some regexp substitutions and such kinds of\n> things).\n\nI have to say that you are quite mistaken.\n\nScripted style bulk modification that indiscriminately touch\neverbody but actually only modifies some, e.g. \"perl -p -i\", is\na fine component of people's workflow, but that is *NOT* the\nnorm. If it were, then you are not programming nor editing --\nyour script is doing the work. But as you know, after such a\nbulk operation, you can always...\n\n> ... until I run git-status again.\n\n... refresh away the cache-dirtiness.\n\nThe default should be tuned for users who perform manual editing\nwith status checks. And power users like yourself who run \"bulk\ntouch indiscriminately but modify only some\" scripts should\nlearn to run git-status (or \"update-index --refresh\") after such\noperation. Swapping the defaults to optimize for the abnormal\ncase is madness.\n"},{"id":"49405","messageId":"vpqbqdq45ua.fsf@bauges.imag.fr","threadId":"9342","inReplyTo":"Pine.LNX.4.64.0708021050500.14781@racer.site","subject":"Re: git-diff on touched files: bug or feature?","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2007-08-02T09:57:01Z","receivedAt":"2007-08-02T09:57:01Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Johannes Schindelin writes:\n\n> On Thu, 2 Aug 2007, Matthieu Moy wrote:\n>\n>> > If the feature still makes sense in the modern world is a\n>> > different story, but I do find it useful.\n>> \n>> I understand that it can be usefull, but I really don't like having it\n>> by default (is there a way to deactivate it BTW?).\n>\n> Yes. Just call \"git status\" and be done with it.\n\nThat's not what I mean (my original message mentionned that already\nBTW). By \"deactivate\", I mean \"make git-diff never show empty diffs\".\nI don't want to run two commands where I need only one.\n\n-- \nMatthieu\n"},{"id":"49406","messageId":"7v1wemxnkk.fsf@assigned-by-dhcp.cox.net","threadId":"9342","inReplyTo":"7vd4y6xnw4.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-diff on touched files: bug or feature?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-08-02T10:01:15Z","receivedAt":"2007-08-02T10:01:15Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Matthieu Moy writes:\n> ...\n>> I've hit this while working on a project, doing a lot of modifications\n>> through scripting (some regexp substitutions and such kinds of\n>> things).\n>\n> I have to say that you are quite mistaken.\n>\n> Scripted style bulk modification that indiscriminately touch\n> everbody but actually only modifies some, e.g. \"perl -p -i\", is\n> a fine component of people's workflow, but that is *NOT* the\n> norm.\n\nHaving said that, there is another lesson to take home from\nthis.\n\nQuite honestly, a script that indiscriminately touches everybody\nbut only modifies a few is simply broken. Think about \"make\".\n\"git diff\" reporting many cache-dirty files is simply reminding\nyou the brokenness of such a script.\n"},{"id":"49413","messageId":"Pine.LNX.4.64.0708021147110.14781@racer.site","threadId":"9342","inReplyTo":"vpqbqdq45ua.fsf@bauges.imag.fr","subject":"Re: git-diff on touched files: bug or feature?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-08-02T10:48:27Z","receivedAt":"2007-08-02T10:48:27Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 2 Aug 2007, Matthieu Moy wrote:\n\n> Johannes Schindelin writes:\n> \n> > On Thu, 2 Aug 2007, Matthieu Moy wrote:\n> >\n> >> > If the feature still makes sense in the modern world is a\n> >> > different story, but I do find it useful.\n> >> \n> >> I understand that it can be usefull, but I really don't like having it\n> >> by default (is there a way to deactivate it BTW?).\n> >\n> > Yes. Just call \"git status\" and be done with it.\n> \n> That's not what I mean (my original message mentionned that already\n> BTW). By \"deactivate\", I mean \"make git-diff never show empty diffs\".\n> I don't want to run two commands where I need only one.\n\nThen don't touch the files you do not want to touch! Or if you want to \nhave it convenient, and have a script that touches everything, even if it \ndoes not change the contents, just add \"git add -u\" at the end of the \nscript\". Not that difficult.\n\nCiao,\nDscho\n"},{"id":"49414","messageId":"vpq4pji3zwm.fsf@bauges.imag.fr","threadId":"9342","inReplyTo":"7vd4y6xnw4.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-diff on touched files: bug or feature?","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2007-08-02T12:05:13Z","receivedAt":"2007-08-02T12:05:13Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Junio C Hamano writes:\n\n> The default should be tuned for users who perform manual editing\n> with status checks. And power users like yourself who run \"bulk\n> touch indiscriminately but modify only some\" scripts should\n> learn to run git-status (or \"update-index --refresh\") after such\n> operation. Swapping the defaults to optimize for the abnormal\n> case is madness.\n\nI fully agree that git should be optimized for the common case. But\neven for the common case, I also find the feature strange. You didn't\nanswer that part of my message, but I still fail to see a rationale\nfor making \"git-diff; git-status\" different from \"git-status; git-diff\".\n\nIOW, why should people running git-status before git-diff not get a\nreminder if you think people running git-diff without or before\ngit-status should get it?\n\n-- \nMatthieu\n"},{"id":"49415","messageId":"vpqzm1a2l72.fsf@bauges.imag.fr","threadId":"9342","inReplyTo":"7v1wemxnkk.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-diff on touched files: bug or feature?","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2007-08-02T12:08:17Z","receivedAt":"2007-08-02T12:08:17Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Junio C Hamano writes:\n\n> Quite honestly, a script that indiscriminately touches everybody\n> but only modifies a few is simply broken. Think about \"make\".\n> \"git diff\" reporting many cache-dirty files is simply reminding\n> you the brokenness of such a script.\n\nI wouldn't call this \"broken\", but clearly suboptimal, yes. But for an\noccasionnal one-liner (perl -pi -e ... or so), I lose less time\nrecompiling extra-files than I would writting a cleaner script. \"make\"\nhas no way to detect the absence of modification, while git has.\n\n-- \nMatthieu\n"},{"id":"49416","messageId":"Pine.LNX.4.64.0708021315510.14781@racer.site","threadId":"9342","inReplyTo":"vpq4pji3zwm.fsf@bauges.imag.fr","subject":"Re: git-diff on touched files: bug or feature?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-08-02T12:19:55Z","receivedAt":"2007-08-02T12:19:55Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 2 Aug 2007, Matthieu Moy wrote:\n\n> Junio C Hamano writes:\n> \n> > The default should be tuned for users who perform manual editing\n> > with status checks. And power users like yourself who run \"bulk\n> > touch indiscriminately but modify only some\" scripts should\n> > learn to run git-status (or \"update-index --refresh\") after such\n> > operation. Swapping the defaults to optimize for the abnormal\n> > case is madness.\n> \n> I fully agree that git should be optimized for the common case. But\n> even for the common case, I also find the feature strange. You didn't\n> answer that part of my message, but I still fail to see a rationale\n> for making \"git-diff; git-status\" different from \"git-status; git-diff\".\n\nFor performance reasons, git always compares the files' stat information \nwith that stored in the index.\n\nBy updating the file, you make that check fail always.\n\nWithout updating the index (which is not a read-only operation, and \ntherefore must not be done when doing a read-only operation like diff), \nyou will therefore _destroy_ the main reason of git's kick-ass \nperformance.\n\nSo when you do \"git diff\" and it tells you all those diff lines, while no \nfile was really changed, it tells you \"get your act together! You just \n_willfully_ slowed down git's performance\".\n\nOkay?\n\nCiao,\nDscho\n\nP.S.: I wish we had something similar for the cases that you did not \"git \ngc\", so that people, posting to their blogs all over the world that they \nbecame benchmark experts overnight and tested git and it sucks, would know \nthat it is not git that sucks.\n"},{"id":"49417","messageId":"Pine.LNX.4.64.0708021320560.14781@racer.site","threadId":"9342","inReplyTo":"vpqzm1a2l72.fsf@bauges.imag.fr","subject":"Re: git-diff on touched files: bug or feature?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-08-02T12:21:27Z","receivedAt":"2007-08-02T12:21:27Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 2 Aug 2007, Matthieu Moy wrote:\n\n> Junio C Hamano writes:\n> \n> > Quite honestly, a script that indiscriminately touches everybody\n> > but only modifies a few is simply broken. Think about \"make\".\n> > \"git diff\" reporting many cache-dirty files is simply reminding\n> > you the brokenness of such a script.\n> \n> I wouldn't call this \"broken\", but clearly suboptimal, yes. But for an\n> occasionnal one-liner (perl -pi -e ... or so), I lose less time\n> recompiling extra-files than I would writting a cleaner script. \"make\"\n> has no way to detect the absence of modification, while git has.\n\n_You_ can afford compiling them extra-files.\n\nThat is _exactly_ what Junio meant by \"corner case\".\n\nCiao,\nDscho\n"},{"id":"49419","messageId":"vpqir7y15sr.fsf@bauges.imag.fr","threadId":"9342","inReplyTo":"Pine.LNX.4.64.0708021315510.14781@racer.site","subject":"Re: git-diff on touched files: bug or feature?","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2007-08-02T12:26:12Z","receivedAt":"2007-08-02T12:26:12Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Johannes Schindelin writes:\n\n>> I fully agree that git should be optimized for the common case. But\n>> even for the common case, I also find the feature strange. You didn't\n>> answer that part of my message, but I still fail to see a rationale\n>> for making \"git-diff; git-status\" different from \"git-status; git-diff\".\n>\n> For performance reasons, git always compares the files' stat information \n> with that stored in the index.\n\nI know that, but how does it answer the part of my message that you\nare citing?\n\n> So when you do \"git diff\" and it tells you all those diff lines, while no \n> file was really changed, it tells you \"get your act together! You just \n> _willfully_ slowed down git's performance\".\n\nThe question remains: why should someone running git-diff get this,\nand someone running git-status not get this?\n\n(I mean, from the user point of view, not the implementation point of\nview)\n\n-- \nMatthieu\n"},{"id":"49421","messageId":"20070802132541.GA9247@localdomain","threadId":"9342","inReplyTo":"Pine.LNX.4.64.0708021315510.14781@racer.site","subject":"Re: git-diff on touched files: bug or feature?","fromName":"Joel Reed","fromEmail":"joelwreed@gmail.com","sentAt":"2007-08-02T13:25:41Z","receivedAt":"2007-08-02T13:25:41Z","isPatch":false,"sender":{"key":"joelwreed@gmail.com","avatar":null},"body":"On Thu, Aug 02, 2007 at 01:19:55PM +0100, Johannes Schindelin wrote:\n\n\n\n> For performance reasons, git always compares the files' stat information \n> with that stored in the index.\n> \n> By updating the file, you make that check fail always.\n> \n> Without updating the index (which is not a read-only operation, and \n> therefore must not be done when doing a read-only operation like diff), \n> you will therefore _destroy_ the main reason of git's kick-ass \n> performance.\n\nThe idea that read-only operation like diff shouldn't update the\nindex makes a lot of sense.\n\nBut, as a user of git and not a git developer, I certainly _thought_\nthat git-status was a read-only operation as well. Now I know it\nisn't, but this doesn't seem very consistent.\n\njr\n"},{"id":"49423","messageId":"AF1190E2-A0F4-479F-B0A1-50B2C7278995@yahoo.ca","threadId":"9342","inReplyTo":"Pine.LNX.4.64.0708021147110.14781@racer.site","subject":"Re: git-diff on touched files: bug or feature?","fromName":"Jean-François Veillette","fromEmail":"jean_francois_veillette@yahoo.ca","sentAt":"2007-08-02T14:04:52Z","receivedAt":"2007-08-02T14:04:52Z","isPatch":false,"sender":{"key":"jean_francois_veillette@yahoo.ca","avatar":null},"body":"I find comments like this to be counter productive.\nAdmin it, git porcelain still has some work to be done. We can't \nexpect new users to know the git internals workflow before they can \nuse git effectively. We can expect new users to read the man pages, \nbut not necessarely expect them to understand all the plumbing \nimplied by what they read. Here I think M.Moy understand the \nplumbing and could silently deal with it. But instead he decided to \nhelp improve git and decided to raise a flag about inconsistencies he \nfaced. We should never answer request for improvement with ' Just do \nX and be done with it'. This is a 'geek' answer to a legitime comment.\n\nI know the goal of git is not to reign over the world of vcs, but \nit's not a reason to refuse to improve it when constructive comments \nare made about it.\n\n- jfv\n\nLe 07-08-02 à 06:48, Johannes Schindelin a écrit :\n\n> Hi,\n>\n> On Thu, 2 Aug 2007, Matthieu Moy wrote:\n>\n>> Johannes Schindelin writes:\n>>\n>>> On Thu, 2 Aug 2007, Matthieu Moy wrote:\n>>>\n>>>>> If the feature still makes sense in the modern world is a\n>>>>> different story, but I do find it useful.\n>>>>\n>>>> I understand that it can be usefull, but I really don't like \n>>>> having it\n>>>> by default (is there a way to deactivate it BTW?).\n>>>\n>>> Yes. Just call \"git status\" and be done with it.\n>>\n>> That's not what I mean (my original message mentionned that already\n>> BTW). By \"deactivate\", I mean \"make git-diff never show empty diffs\".\n>> I don't want to run two commands where I need only one.\n>\n> Then don't touch the files you do not want to touch! Or if you \n> want to\n> have it convenient, and have a script that touches everything, even \n> if it\n> does not change the contents, just add \"git add -u\" at the end of the\n> script\". Not that difficult.\n>\n> Ciao,\n> Dscho\n"},{"id":"49425","messageId":"Pine.LNX.4.64.0708021537490.14781@racer.site","threadId":"9342","inReplyTo":"vpqir7y15sr.fsf@bauges.imag.fr","subject":"Re: git-diff on touched files: bug or feature?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-08-02T14:39:20Z","receivedAt":"2007-08-02T14:39:20Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 2 Aug 2007, Matthieu Moy wrote:\n\n> Johannes Schindelin writes:\n> \n> >> I fully agree that git should be optimized for the common case. But\n> >> even for the common case, I also find the feature strange. You didn't\n> >> answer that part of my message, but I still fail to see a rationale\n> >> for making \"git-diff; git-status\" different from \"git-status; git-diff\".\n> >\n> > For performance reasons, git always compares the files' stat information \n> > with that stored in the index.\n> \n> I know that, but how does it answer the part of my message that you\n> are citing?\n\nYou _acknowledge_ that git is optimized for performance! And therefore \nyou should also acknowledge that you _throw that away_ if you let your \nindex go out of sync.\n\n> > So when you do \"git diff\" and it tells you all those diff lines, while no \n> > file was really changed, it tells you \"get your act together! You just \n> > _willfully_ slowed down git's performance\".\n> \n> The question remains: why should someone running git-diff get this,\n> and someone running git-status not get this?\n\nBecause git-status is an index-updating operation. That's why.\n\nCiao,\nDscho\n"},{"id":"49426","messageId":"Pine.LNX.4.64.0708021541520.14781@racer.site","threadId":"9342","inReplyTo":"AF1190E2-A0F4-479F-B0A1-50B2C7278995@yahoo.ca","subject":"Re: git-diff on touched files: bug or feature?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-08-02T14:43:30Z","receivedAt":"2007-08-02T14:43:30Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\n[please do not top-post. Either comment on what you quote, or delete it.]\n\nOn Thu, 2 Aug 2007, Jean-Fran?ois Veillette wrote:\n\n> Admin it, git porcelain still has some work to be done.\n\nNo need to argue there, I admit it.\n\n> We can't expect new users to know the git internals workflow before they \n> can use git effectively.\n\nThis use case has not much to do with new users. A new user _has_ to know \nthat updating all files, even if their content does not change, is not \nright.\n\nAt least we do not commit empty changes like CVS did all too happily.\n\nCiao,\nDscho\n"},{"id":"49428","messageId":"vpq7ioeyosh.fsf@bauges.imag.fr","threadId":"9342","inReplyTo":"Pine.LNX.4.64.0708021537490.14781@racer.site","subject":"Re: git-diff on touched files: bug or feature?","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2007-08-02T14:49:34Z","receivedAt":"2007-08-02T14:49:34Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Johannes Schindelin writes:\n\n>> The question remains: why should someone running git-diff get this,\n>> and someone running git-status not get this?\n>\n> Because git-status is an index-updating operation. That's why.\n\nThat sounds like \"it is this way because it is not the other way\naround\".\n\nSo, yes, git-status updates the index because it's an index-updating\noperation, while git-diff does not update the index because it's a\nnon-index-updating operation.\n\nThen, I'll rephrase my sentence as \"*why* is git-status an\nindex-updating operation while git-diff is not\". But you'll probably\nfind another way to avoid answering.\n\n-- \nMatthieu\n"},{"id":"49429","messageId":"Pine.LNX.4.64.0708021605170.14781@racer.site","threadId":"9342","inReplyTo":"20070802132541.GA9247@localdomain","subject":"Re: git-diff on touched files: bug or feature?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-08-02T15:05:36Z","receivedAt":"2007-08-02T15:05:36Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 2 Aug 2007, Joel Reed wrote:\n\n> On Thu, Aug 02, 2007 at 01:19:55PM +0100, Johannes Schindelin wrote:\n> \n> \n> \n> > For performance reasons, git always compares the files' stat information \n> > with that stored in the index.\n> > \n> > By updating the file, you make that check fail always.\n> > \n> > Without updating the index (which is not a read-only operation, and \n> > therefore must not be done when doing a read-only operation like diff), \n> > you will therefore _destroy_ the main reason of git's kick-ass \n> > performance.\n> \n> The idea that read-only operation like diff shouldn't update the\n> index makes a lot of sense.\n> \n> But, as a user of git and not a git developer, I certainly _thought_\n> that git-status was a read-only operation as well. Now I know it\n> isn't, but this doesn't seem very consistent.\n\nI'll not go into details again. See \nhttp://thread.gmane.org/gmane.comp.version-control.git/40205/focus=40339\n\nCiao,\nDscho\n"},{"id":"49431","messageId":"46B1F3F4.5030504@midwinter.com","threadId":"9342","inReplyTo":"Pine.LNX.4.64.0708021541520.14781@racer.site","subject":"Re: git-diff on touched files: bug or feature?","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2007-08-02T15:10:44Z","receivedAt":"2007-08-02T15:10:44Z","isPatch":false,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"Johannes Schindelin wrote:\n> This use case has not much to do with new users. A new user _has_ to know \n> that updating all files, even if their content does not change, is not \n> right.\n> \n\nSomeone who has used, say, Subversion might have a perfectly reasonable \nexpectation that \"git diff\" will show differences in content, and when \nthere are no differences in content, will not mention a file at all. \nOther version control systems have \"diff\" commands that ignore touched \nfiles.\n\nI admit I also thought the empty diffs were a bug (albeit a minor one \nnot worth making noise about) until this thread. Now I understand why it \nhappens, though I still think we'd be better off just not displaying the \nfilename in git-diff until we know there's an actual diff to display.\n\nI certainly don't think the \"it's a feature: it reminds you when you've \nedited a file without changing it\" argument holds any water at all. If \nthat were truly the intent, if we truly considered that to be useful \ninformation a developer would want to get at after the fact, then why \nwould git-status throw away that information? If I check to see what \nfiles I've modified/added (for which I run git-status) why does that \nautomatically imply I am no longer interested in being reminded that I \nhave saved a file without making changes, especially given that such \nfiles *don't* show up in the git-status output? git-status is silently \nlosing information here; it gives you no indication that it has \nrefreshed the index for those touched-but-not-edited files.\n\nNow, I happen to think throwing away that information is just fine, \nbecause I don't think I have ever once cared to know that I touched a \nfile but didn't change it. But fundamentally it's either a piece of \ninformation we care about (in which case we shouldn't go silently \ndiscarding it) or not (in which case it is just clutter in git-diff).\n\nIn the meantime, though, it's trivial enough to put a wrapper around \ngit-diff to filter out the diffless files. I haven't cared enough to \nbother, but if I did it'd be just a few lines of Perl, no big deal.\n\n-Steve\n"},{"id":"49432","messageId":"Pine.LNX.4.64.0708021612080.14781@racer.site","threadId":"9342","inReplyTo":"vpq7ioeyosh.fsf@bauges.imag.fr","subject":"Re: git-diff on touched files: bug or feature?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-08-02T15:12:51Z","receivedAt":"2007-08-02T15:12:51Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 2 Aug 2007, Matthieu Moy wrote:\n\n> Johannes Schindelin writes:\n> \n> >> The question remains: why should someone running git-diff get this,\n> >> and someone running git-status not get this?\n> >\n> > Because git-status is an index-updating operation. That's why.\n> \n> That sounds like \"it is this way because it is not the other way\n> around\".\n> \n> So, yes, git-status updates the index because it's an index-updating\n> operation, while git-diff does not update the index because it's a\n> non-index-updating operation.\n> \n> Then, I'll rephrase my sentence as \"*why* is git-status an\n> index-updating operation while git-diff is not\". But you'll probably\n> find another way to avoid answering.\n\nYes. I do. The issue whether or not git status should be a read-only \noperation has been discussed -- in _length_ -- here:\n\nhttp://thread.gmane.org/gmane.comp.version-control.git/40205/focus=40339\n\nCiao,\nDscho\n"},{"id":"49433","messageId":"Pine.LNX.4.64.0708021614420.14781@racer.site","threadId":"9342","inReplyTo":"46B1F3F4.5030504@midwinter.com","subject":"Re: git-diff on touched files: bug or feature?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-08-02T15:23:38Z","receivedAt":"2007-08-02T15:23:38Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 2 Aug 2007, Steven Grimm wrote:\n\n> Johannes Schindelin wrote:\n> > This use case has not much to do with new users. A new user _has_ to know\n> > that updating all files, even if their content does not change, is not\n> > right.\n> > \n> \n> Someone who has used, say, Subversion might have a perfectly reasonable\n> expectation that \"git diff\" will show differences in content, and when there\n> are no differences in content, will not mention a file at all. Other version\n> control systems have \"diff\" commands that ignore touched files.\n> \n> I admit I also thought the empty diffs were a bug (albeit a minor one not\n> worth making noise about) until this thread. Now I understand why it happens,\n> though I still think we'd be better off just not displaying the filename in\n> git-diff until we know there's an actual diff to display.\n> \n> I certainly don't think the \"it's a feature: it reminds you when you've edited\n> a file without changing it\" argument holds any water at all. If that were\n> truly the intent, if we truly considered that to be useful information a\n> developer would want to get at after the fact, then why would git-status throw\n> away that information?\n\nOkay, I'll answer just this one, instead of pointing you to the thread \nthat I've been pointing to twice now (because your ideas about how \ngit should work are usually similar to mine, and by way of saying thanks \nfor your contributions):\n\nWhen is the time to say \"git status\"?\n\nIt is just before committing. I.e when you really think that you're done \nediting, and want to have the end picture. \"git status\" only gives you \nnames, and therefore it _has_ to update the index if it got out of sync, \nto show meaningful results.\n\nWhen is the time to say \"git diff\"?\n\nMuch more often. In the middle of your work. And there it would be \n_disruptive_ if it updated the index all the time, especially if you have \na quite large working tree.\n\nBut then, normal users do not touch all the files. They don't.\n\nSo I doubt that in the common case the subject we are discussing matters \nat all.\n\nYes, \"perl -pi\" is something I used myself. Yes, I think it is a bug that \nit writes new files when it does not really change anything. And yes, I \nhad a script lying somewhere on my backup hard disk which uses some evil \n\"git diff --name-only | xargs bla\" mantra (it does not even use the \n--quiet option, since that was not invented back then) to actually _undo_ \nthe effects by setting the timestamps back, since the full compilation \ntime in that project _hurt_.\n\nBut it is hardly an operation that I use daily. Hardly even twice a \nyear.\n\nCiao,\nDscho\n"},{"id":"49439","messageId":"vpqtzrivt2n.fsf@bauges.imag.fr","threadId":"9342","inReplyTo":"Pine.LNX.4.64.0708021614420.14781@racer.site","subject":"Re: git-diff on touched files: bug or feature?","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2007-08-02T15:45:20Z","receivedAt":"2007-08-02T15:45:20Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Johannes Schindelin writes:\n\n> Okay, I'll answer just this one, instead of pointing you to the thread \n> that I've been pointing to twice now\n\nThe link was probably not the right one since I saw only two [PATCH]\nmessage, but yes, I remember a thread pointing out why git-status had\nto update the index. I'm not arguing against that, I'm happy with the\ncurrent git-status behavior, but I find the git-diff one inconsistant\nwith git-status, and still don't understand any reason why a normal\nuser would want a difference.\n\n> When is the time to say \"git status\"?\n>\n> It is just before committing. I.e when you really think that you're done \n> editing, and want to have the end picture. \"git status\" only gives you \n> names, and therefore it _has_ to update the index if it got out of sync, \n> to show meaningful results.\n>\n> When is the time to say \"git diff\"?\n>\n> Much more often. In the middle of your work. And there it would be \n> _disruptive_ if it updated the index all the time, especially if you have \n> a quite large working tree.\n\nThat's your point of view, but I do not share it. Depending on the\nkind of things I'm doing, I usually run status regularly, because it's\nshort to read, and it shows me both staged and unstaged changes.\ngit-status tells me if I did something obviously totally wrong\n(changing a file on which I was not working, deleting something\nimportant ...), and after that, git-diff gives me a finer-grained\nvision of what I did.\n\nDoes this really sound so much irreasonable to you?\n\n-- \nMatthieu\n"},{"id":"49450","messageId":"20070802175838.GA31885@fieldses.org","threadId":"9342","inReplyTo":"vpqtzrivt2n.fsf@bauges.imag.fr","subject":"Re: git-diff on touched files: bug or feature?","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2007-08-02T17:58:38Z","receivedAt":"2007-08-02T17:58:38Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Thu, Aug 02, 2007 at 05:45:20PM +0200, Matthieu Moy wrote:\n> Depending on the kind of things I'm doing, I usually run status\n> regularly, because it's short to read, and it shows me both staged and\n> unstaged changes. git-status tells me if I did something obviously\n> totally wrong (changing a file on which I was not working, deleting\n> something important ...), and after that, git-diff gives me a\n> finer-grained vision of what I did.\n\nYeah, ditto for me. When I return to a project after having been away a\nfew minutes, the first things I do are\n\n\tgit branch\t# remind me which topic I was working on\n\tgit status\t# remind me if I was in the middle of something.\n\nSo I end up running it a lot. I only do a git-diff if I need some\ndetails.\n\n--b.\n"},{"id":"49462","messageId":"7vy7gtvhgc.fsf@assigned-by-dhcp.cox.net","threadId":"9342","inReplyTo":"vpqzm1a2l72.fsf@bauges.imag.fr","subject":"Re: git-diff on touched files: bug or feature?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-08-02T19:56:19Z","receivedAt":"2007-08-02T19:56:19Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy writes:\n\n> Junio C Hamano writes:\n>\n>> Quite honestly, a script that indiscriminately touches everybody\n>> but only modifies a few is simply broken. Think about \"make\".\n>> \"git diff\" reporting many cache-dirty files is simply reminding\n>> you the brokenness of such a script.\n>\n> I wouldn't call this \"broken\", but clearly suboptimal, yes. But for an\n> occasionnal one-liner (perl -pi -e ... or so), I lose less time\n> recompiling extra-files than I would writting a cleaner script. \"make\"\n> has no way to detect the absence of modification, while git has.\n\nThe first part of your sentence makes sense. You are trading\n\"make\" time with the reduction in effort to write a throw-away\nscript. That makes sense --- and you pay with a more expensive\nmake, but that is a valid tradeoff you choose to make. You can\njust choose to make the same tradeoff by running an extra\nrefresh.\n\nYou could do something like the trivial patch attached below to\nsquelch diff-files \"cache-dirty\" output, if you wanted to.\n\nAfter trying to work with this modified git for some time,\nhowever, it has become very clear that doing this and nothing\nelse is a stupid thing to do (I'll suggest potential\nimprovements at the end). For one thing, it obviously loses the\n\"quick git-diff to see what I touched\" benefit. And that issue\nis real, as I first touched diff-lib.c to come up with this\nuntil I realized that doing it in here is much cleaner and\nsimpler --- this patch is discarding that information, and makes\nwriting a changelog for this patch, if it were to be included,\nmore expensive for the user -- that is me.\n\nAnother thing is that it loses the coal-mine canary value the\n\"cache-dirty\" output has. After running a loosely written bulk\nregexp script, like this:\n\n\tperl -p -i -e 's/foo/bar/' *.c\n\nthe cached stat data are destroyed for all paths, and it makes\nall the subsequent git worktree operations needlessly more\nexpensive; existing output makes me realize this situation.\n\nIt is not a stupid thing to run such a script [*1*]; in this\ncase, I am choosing the convenience of using such a suboptimal\n(as you said) script. But after running such a script, I DO\nWANT git to tell me that I made the index suboptimal, so that I\ncan and should refresh it to gain the lost performance back.\n\nPersonally, I almost never run \"git status\". The command is\nthere primarily because other systems had a command called\n\"status\", and migrant wondered why we didn't. We do not need\nit, and we do not have to use it.\n\n * For getting the status so-far, I use \"git diff\" (and \"git\n diff .\" when in a subdirectory). It is \"how have I changed\n things?\", and that is when it is very useful to know \"ah, I\n originally went in that direction but decided against it and\n did it differently\" by the cache-dirtiness output. The\n coal-mine canary value is also felt here;\n\n * For a quick final status, \"git diff --stat\" is much simpler\n to read than \"git status\", and that is what I use. It is\n \"what have I changed overall?\". As this actually counts the\n real changes, you would not see those null changes that come\n from the cache dirtiness you are complaining about;\n\n * When I am ready to commit, \"git status\" output comes in the\n commit log editor. At that point, I already have been\n reminded by the previous \"git diff\" (which is usually run\n often unless the patch is very small like this), and I do not\n need cache-dirtiness output anymore after making my commit.\n\nYou do not have to say, to the above paragraph, that it is\ndifferent from your workflow. I am showing what the opmimum\nworkflow would be, and it is up to you not to listen to me.\n\nEven if we were willing to lose the \"quick git-diff to see what\nI touched\" benefit and want to go the route of the attached\npatch suggests (which I personally do not think we are), there\nshould be a way to either (1) tell the user that many paths are\nfound to be cache-dirty and it is a good idea to refresh the\nstat information, after squelching diff-files output this way,\nor (2) update the stat information automatically when diff-files\nfinds too many paths are cache-dirty (perhaps without even\ntelling the user). The latter requires you to declare that\ngit-diff is not a read-only operation anymore, though, so you\nwould need some thought before going in that direction.\n\n\n[Footnote]\n\n*1* Some people might argue that \"perl -i\" should have a mode to\nleave the original if the script does not modify the contents.\nMaybe they are right, but that is an orthogonal issue.\n\n---\n\n diff.c | 40 ++++++++++++++++++++++++++++++++++++++++\n 1 files changed, 40 insertions(+), 0 deletions(-)\n\ndiff --git a/diff.c b/diff.c\nindex a5fc56b..ea1239d 100644\n--- a/diff.c\n+++ b/diff.c\n@@ -3143,6 +3143,45 @@ static void diffcore_apply_filter(const char *filter)\n \t*q = outq;\n }\n \n+static void diffcore_remove_empty(void)\n+{\n+\tint i;\n+\tstruct diff_queue_struct *q = &diff_queued_diff;\n+\tstruct diff_queue_struct outq;\n+\toutq.queue = NULL;\n+\toutq.nr = outq.alloc = 0;\n+\n+\tfor (i = 0; i < q->nr; i++) {\n+\t\tstruct diff_filepair *p = q->queue[i];\n+\n+\t\t/*\n+\t\t * 1. Keep the ones that cannot be diff-files\n+\t\t * \"false\" match that are only queued due to\n+\t\t * cache dirtyness.\n+\t\t *\n+\t\t * 2. Modified, same size and mode, and the object\n+\t\t * name of one side is unknown. If they do not\n+\t\t * have identical contents, keep them.\n+\t\t * They are different.\n+\t\t */\n+\t\tif ((p->status != DIFF_STATUS_MODIFIED) || /* (1) */\n+\t\t (p->one->sha1_valid && p->two->sha1_valid) ||\n+\t\t (p->one->mode != p->two->mode) ||\n+\n+\t\t diff_populate_filespec(p->one, 1) || /* (2) */\n+\t\t diff_populate_filespec(p->two, 1) ||\n+\t\t (p->one->size != p->two->size) ||\n+\t\t diff_populate_filespec(p->one, 0) ||\n+\t\t diff_populate_filespec(p->two, 0) ||\n+\t\t memcmp(p->one->data, p->two->data, p->one->size))\n+\t\t\tdiff_q(&outq, p);\n+\t\telse\n+\t\t\tdiff_free_filepair(p);\n+\t}\n+\tfree(q->queue);\n+\t*q = outq;\n+}\n+\n void diffcore_std(struct diff_options *options)\n {\n \tif (options->quiet)\n@@ -3160,6 +3199,7 @@ void diffcore_std(struct diff_options *options)\n \t\tdiffcore_order(options->orderfile);\n \tdiff_resolve_rename_copy();\n \tdiffcore_apply_filter(options->filter);\n+\tdiffcore_remove_empty();\n \n \toptions->has_changes = !!diff_queued_diff.nr;\n }\n"},{"id":"49479","messageId":"7vd4y5vexy.fsf@assigned-by-dhcp.cox.net","threadId":"9342","inReplyTo":"AF1190E2-A0F4-479F-B0A1-50B2C7278995@yahoo.ca","subject":"Re: git-diff on touched files: bug or feature?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-08-02T20:50:33Z","receivedAt":"2007-08-02T20:50:33Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jean-François Veillette \nwrites:\n\n> I find comments like this to be counter productive.\n> Admin it, git porcelain still has some work to be done.\n\nYes, but this certainly is not an area that needs changing.\n"},{"id":"49540","messageId":"20070803053717.GA16379@midwinter.com","threadId":"9342","inReplyTo":"Pine.LNX.4.64.0708021614420.14781@racer.site","subject":"[PATCH] Add --show-touched option to show \"diff --git\" line when contents are unchanged","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2007-08-03T05:37:18Z","receivedAt":"2007-08-03T05:37:18Z","isPatch":true,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"The default is now to not show the diff --git header line if the file's\ntimestamp has changed but the contents and/or file mode haven't.\n\nSigned-off-by: Steven Grimm \n---\n\n\tOkay, enough arguing about whether the empty diff lines are\n\tuseful or not -- here's a patch to get rid of them.\n\n\tThis passes all the existing \"diff\" tests, with one minor tweak\n\tto the symlink test (since it expected the old behavior.)\n\tIf someone can find a case where this will spit out an actual\n\tdiff but not the \"diff --git\" line, please tell me how to make\n\tthat happen. The code *looks* like it has such a path, but I was\n\tunable to make it happen in my ad-hoc testing and it doesn't\n\thappen in any of the existing diff test cases.\n\n\tPersonally I'm in favor of doing away with the option altogether\n\tand having the code always work the way it works by default with\n\tthis patch, but if some people find the old behavior useful they\n\tcan still get at it with the new option.\n\n\tMy xmalloc() call allocates a few more bytes than strictly\n\tneeded, but I found it was less readable to subtract out the\n\tspace taken by the \"%s\" tokens in the format string.\n\n Documentation/diff-options.txt | 4 ++\n diff.c | 46 ++++++++++++++++++++++++++----\n diff.h | 3 +-\n t/t4011-diff-symlink.sh | 2 +-\n t/t4021-diff-untouched.sh | 61 ++++++++++++++++++++++++++++++++++++++++\n 5 files changed, 108 insertions(+), 8 deletions(-)\n create mode 100755 t/t4021-diff-untouched.sh\n\ndiff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt\nindex 228ccaf..12ad048 100644\n--- a/Documentation/diff-options.txt\n+++ b/Documentation/diff-options.txt\n@@ -185,5 +185,9 @@\n --no-ext-diff::\n \tDisallow external diff drivers.\n \n+--show-touched::\n+\tDisplay the \"diff --git\" message for files whose modification\n+\ttimestamps have changed, even if the contents don't differ.\n+\n For more detailed explanation on these common options, see also\n link:diffcore.html[diffcore documentation].\ndiff --git a/diff.c b/diff.c\nindex a5fc56b..e1112e5 100644\n--- a/diff.c\n+++ b/diff.c\n@@ -1260,6 +1260,9 @@ static const char *diff_funcname_pattern(struct diff_filespec *one)\n \treturn NULL;\n }\n \n+/* The message that gets printed at the top of a file's diffs */\n+#define DIFF_MESSAGE_FORMAT_STRING \"%sdiff --git %s %s%s\\n\"\n+\n static void builtin_diff(const char *name_a,\n \t\t\t const char *name_b,\n \t\t\t struct diff_filespec *one,\n@@ -1268,6 +1271,7 @@ static void builtin_diff(const char *name_a,\n \t\t\t struct diff_options *o,\n \t\t\t int complete_rewrite)\n {\n+\tchar *diff_message;\n \tmmfile_t mf1, mf2;\n \tconst char *lbl[2];\n \tchar *a_one, *b_two;\n@@ -1278,25 +1282,50 @@ static void builtin_diff(const char *name_a,\n \tb_two = quote_two(\"b/\", name_b + (*name_b == '/'));\n \tlbl[0] = DIFF_FILE_VALID(one) ? a_one : \"/dev/null\";\n \tlbl[1] = DIFF_FILE_VALID(two) ? b_two : \"/dev/null\";\n-\tprintf(\"%sdiff --git %s %s%s\\n\", set, a_one, b_two, reset);\n+\n+\t/*\n+\t * Generate the \"diff --git\" status message. By default we only\n+\t * show it if we have a difference to display, but the user can\n+\t * optionally choose to show it for all files that we examine for\n+\t * content differences (e.g. because their timestamps have changed.)\n+\t */\n+\tdiff_message = xmalloc(strlen(set) + strlen(reset) +\n+\t\t\t strlen(a_one) + strlen(b_two) +\n+\t\t\t sizeof(DIFF_MESSAGE_FORMAT_STRING));\n+\tsprintf(diff_message, DIFF_MESSAGE_FORMAT_STRING,\n+\t set, a_one, b_two, reset);\n+\tif (o->show_touched) {\n+\t\tfputs(diff_message, stdout);\n+\t\t*diff_message = '\\0';\n+\t}\n+\n \tif (lbl[0][0] == '/') {\n \t\t/* /dev/null */\n-\t\tprintf(\"%snew file mode %06o%s\\n\", set, two->mode, reset);\n+\t\tprintf(\"%s%snew file mode %06o%s\\n\",\n+\t\t diff_message, set, two->mode, reset);\n+\t\t*diff_message = '\\0';\n \t\tif (xfrm_msg && xfrm_msg[0])\n \t\t\tprintf(\"%s%s%s\\n\", set, xfrm_msg, reset);\n \t}\n \telse if (lbl[1][0] == '/') {\n-\t\tprintf(\"%sdeleted file mode %06o%s\\n\", set, one->mode, reset);\n+\t\tprintf(\"%s%sdeleted file mode %06o%s\\n\",\n+\t\t diff_message, set, one->mode, reset);\n+\t\t*diff_message = '\\0';\n \t\tif (xfrm_msg && xfrm_msg[0])\n \t\t\tprintf(\"%s%s%s\\n\", set, xfrm_msg, reset);\n \t}\n \telse {\n \t\tif (one->mode != two->mode) {\n-\t\t\tprintf(\"%sold mode %06o%s\\n\", set, one->mode, reset);\n+\t\t\tprintf(\"%s%sold mode %06o%s\\n\",\n+\t\t\t diff_message, set, one->mode, reset);\n \t\t\tprintf(\"%snew mode %06o%s\\n\", set, two->mode, reset);\n+\t\t\t*diff_message = '\\0';\n+\t\t}\n+\t\tif (xfrm_msg && xfrm_msg[0]) {\n+\t\t\tprintf(\"%s%s%s%s\\n\",\n+\t\t\t diff_message, set, xfrm_msg, reset);\n+\t\t\t*diff_message = '\\0';\n \t\t}\n-\t\tif (xfrm_msg && xfrm_msg[0])\n-\t\t\tprintf(\"%s%s%s\\n\", set, xfrm_msg, reset);\n \t\t/*\n \t\t * we do not run diff between different kind\n \t\t * of objects.\n@@ -1304,6 +1333,8 @@ static void builtin_diff(const char *name_a,\n \t\tif ((one->mode ^ two->mode) & S_IFMT)\n \t\t\tgoto free_ab_and_return;\n \t\tif (complete_rewrite) {\n+\t\t\tfputs(diff_message, stdout);\n+\t\t\t*diff_message = '\\0';\n \t\t\temit_rewrite_diff(name_a, name_b, one, two,\n \t\t\t\t\to->color_diff);\n \t\t\to->found_changes = 1;\n@@ -1372,6 +1403,7 @@ static void builtin_diff(const char *name_a,\n \tdiff_free_filespec_data(two);\n \tfree(a_one);\n \tfree(b_two);\n+\tfree(diff_message);\n \treturn;\n }\n \n@@ -2381,6 +2413,8 @@ int diff_opt_parse(struct diff_options *options, const char **av, int ac)\n \t\toptions->allow_external = 1;\n \telse if (!strcmp(arg, \"--no-ext-diff\"))\n \t\toptions->allow_external = 0;\n+\telse if (!strcmp(arg, \"--show-touched\"))\n+\t\toptions->show_touched = 1;\n \telse\n \t\treturn 0;\n \treturn 1;\ndiff --git a/diff.h b/diff.h\nindex 9fd6d44..e172ecf 100644\n--- a/diff.h\n+++ b/diff.h\n@@ -61,7 +61,8 @@ struct diff_options {\n \t\t has_changes:1,\n \t\t quiet:1,\n \t\t allow_external:1,\n-\t\t exit_with_status:1;\n+\t\t exit_with_status:1,\n+\t\t show_touched:1;\n \tint context;\n \tint break_opt;\n \tint detect_rename;\ndiff --git a/t/t4011-diff-symlink.sh b/t/t4011-diff-symlink.sh\nindex c6d1369..910c6cc 100755\n--- a/t/t4011-diff-symlink.sh\n+++ b/t/t4011-diff-symlink.sh\n@@ -60,7 +60,7 @@ test_expect_success \\\n 'diff identical, but newly created symlink' \\\n 'sleep 3 &&\n ln -s xyzzy frotz &&\n- git diff-index -M -p $tree > current &&\n+ git diff-index --show-touched -M -p $tree > current &&\n compare_diff_patch current expected'\n \n cat > expected << EOF\ndiff --git a/t/t4021-diff-untouched.sh b/t/t4021-diff-untouched.sh\nnew file mode 100755\nindex 0000000..a8153e0\n--- /dev/null\n+++ b/t/t4021-diff-untouched.sh\n@@ -0,0 +1,61 @@\n+#!/bin/sh\n+#\n+# Copyright (c) 2005 Johannes Schindelin\n+#\n+\n+test_description='Test display and suppression of unmodified files.\n+\n+'\n+. ./test-lib.sh\n+. ../diff-lib.sh\n+\n+touch empty\n+\n+test_expect_success 'no output when no changes' '\n+\n+\techo foobar > file1 &&\n+\tchmod 644 file1 &&\n+\tgit add file1 &&\n+\tgit commit -m \"initial commit\" &&\n+\tgit diff > current &&\n+\tcompare_diff_patch current empty\n+'\n+\n+test_expect_success 'no output when file touched' '\n+\n+\tsleep 1 &&\n+\ttouch file1 &&\n+\tgit diff > current &&\n+\tcompare_diff_patch current empty\n+'\n+\n+cat > expected << EOF\n+diff --git a/file1 b/file1\n+EOF\n+\n+test_expect_success 'output when --show-touched is used' '\n+\n+\tgit diff --show-touched > current &&\n+\tcompare_diff_patch current expected\n+'\n+\n+test_expect_success 'no output when index updated with touched file' '\n+\n+\tgit add file1 &&\n+\tgit diff --cached > current &&\n+\tcompare_diff_patch current empty\n+'\n+\n+cat > expected << EOF\n+diff --git a/file1 b/file1\n+old mode 100644\n+new mode 100755\n+EOF\n+\n+test_expect_success 'output when mode is changed' '\n+\n+\tchmod 755 file1 &&\n+\tgit diff > current &&\n+\tcompare_diff_patch current expected\n+'\n+test_done\n-- \n1.5.3.rc2.4.g726f9\n"},{"id":"49548","messageId":"7v3az1qgdg.fsf@assigned-by-dhcp.cox.net","threadId":"9342","inReplyTo":"20070803053717.GA16379@midwinter.com","subject":"Re: [PATCH] Add --show-touched option to show \"diff --git\" line when contents are unchanged","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-08-03T06:30:51Z","receivedAt":"2007-08-03T06:30:51Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Steven Grimm writes:\n\n> \tOkay, enough arguing about whether the empty diff lines are\n> \tuseful or not -- here's a patch to get rid of them.\n\nI do not think this addresses anything but -p (i.e. textual\ndiff) output. If we _were_ to really do this, I think the patch\nI sent earlier today, with possible improvements I suggested,\nwould be a better direction to go.\n"},{"id":"49551","messageId":"20070803070407.GA17287@coredump.intra.peff.net","threadId":"9342","inReplyTo":"7vy7gtvhgc.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-diff on touched files: bug or feature?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-08-03T07:04:07Z","receivedAt":"2007-08-03T07:04:07Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Aug 02, 2007 at 12:56:19PM -0700, Junio C Hamano wrote:\n\n> Personally, I almost never run \"git status\". The command is\n> there primarily because other systems had a command called\n> \"status\", and migrant wondered why we didn't. We do not need\n> it, and we do not have to use it.\n\nSo what is the recommended command to summarize which files have been\nmodified, which files have been marked for commit, and which remain\nuntracked?\n\nI find \"git-diff --stat\" totally insufficient for seeing the progress of\nmy work. How will it remind me that I have also previously git-added\nsome changes? They won't be mentioned at all, unless you are really\nadvocating \"git-diff --stat HEAD\". How will I be reminded that some\nfiles from my work need to be git-added? git-diff won't mention\nuntracked files at all.\n\n> You do not have to say, to the above paragraph, that it is\n> different from your workflow. I am showing what the opmimum\n> workflow would be, and it is up to you not to listen to me.\n\nYou are throwing the word \"optimum\" out here, but I have no idea what\nyou mean in this context. Optimum with respect to what criteria?\n\nI know you are just trying to show your workflow, and that you\nunderstand that others might have a different workflow. But you seem to\nbe implying that workflows using \"git-status\" are lesser for some\nreason, and I really think it is a matter of taste.\n\n-Peff\n"},{"id":"49559","messageId":"7vr6mlnj4g.fsf@assigned-by-dhcp.cox.net","threadId":"9342","inReplyTo":"20070803070407.GA17287@coredump.intra.peff.net","subject":"Re: git-diff on touched files: bug or feature?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-08-03T07:59:43Z","receivedAt":"2007-08-03T07:59:43Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Thu, Aug 02, 2007 at 12:56:19PM -0700, Junio C Hamano wrote:\n>\n>> Personally, I almost never run \"git status\". The command is\n>> there primarily because other systems had a command called\n>> \"status\", and migrant wondered why we didn't. We do not need\n>> it, and we do not have to use it.\n>\n> So what is the recommended command to summarize which files have been\n> modified, which files have been marked for commit, and which remain\n> untracked?\n\nOk, you got me. If I need such a summary, git-status would\nobviously be the choice. Although I do admit that I added the\ninteractive commit to support people who want to keep 30 hunks\nacross 10 different files in the working tree, and make a commit\nusing only 3 of them, I do not make partial commits myself, so\ndistinction between staged and unstaged are not something I am\nusually interested in. If your workflow care about that\ndistinction, and that is a very valid and natural workflow in\ngit, you would find git-status and git-diff --cached more useful\nthan they are to me. I should not used words such as optimum.\nIt is just \"different\".\n\nWhen you think about it, in such a workflow whose work tree that\ndoes not match commits created from it, it is not very useful to\nknow the \"touched but ended up unmodified\", because (1) the\nworktree changes are full of not-yet-ready changes (to the\nimmediate commit you are going to create) anyway, and (2) the\n\"touched but not modified\" files may further be modified and\nbecome modified before their changes hit a (later) commit. The\nside effect that \"git-status\" loses that information suddenly\nbecomes a useful feature for such a workflow.\n\nOn the other hand, if your workflow is \"work on one thing at a\ntime, and never make partial commits\", then your diff tends to\nbe small and more focused to begin with, and you can afford to\ncare about \"touched but ended up unmodified\". Interestingly, it\nhappens to be a useful correlation that \"git status\", which\nclears such information, is less useful command for such a\nworkflow.\n"},{"id":"49561","messageId":"20070803082435.GA15475@coredump.intra.peff.net","threadId":"9342","inReplyTo":"7vr6mlnj4g.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-diff on touched files: bug or feature?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-08-03T08:24:36Z","receivedAt":"2007-08-03T08:24:36Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Aug 03, 2007 at 12:59:43AM -0700, Junio C Hamano wrote:\n\n> On the other hand, if your workflow is \"work on one thing at a\n> time, and never make partial commits\", then your diff tends to\n> be small and more focused to begin with, and you can afford to\n> care about \"touched but ended up unmodified\". Interestingly, it\n\nIn an ideal world, I would work that way. But often you uncover a bug in\nexisting code while writing new code, and you want to make that bugfix a\nseparate commit. I generally make a partial commit to stash the bugfix\nand test it individually. Without making a partial commit, how would you\nsplit the bugfix changes from the working changes? Or do you manually\npull the bugfix into another branch or working tree?\n\nThere is one point you didn't address from my original mail which I\nwould be curious to hear your take on. In your workflow, how do you\nremind yourself that there are untracked files that need to be added? Do\nyou just wait until you see the commit template at the end?\n\n-Peff\n"},{"id":"49564","messageId":"20070803084010.GM20052@spearce.org","threadId":"9342","inReplyTo":"7vr6mlnj4g.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-diff on touched files: bug or feature?","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-08-03T08:40:10Z","receivedAt":"2007-08-03T08:40:10Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano wrote:\n> > On Thu, Aug 02, 2007 at 12:56:19PM -0700, Junio C Hamano wrote:\n> >\n> >> Personally, I almost never run \"git status\". The command is\n> >> there primarily because other systems had a command called\n> >> \"status\", and migrant wondered why we didn't. We do not need\n> >> it, and we do not have to use it.\n> >\n> > So what is the recommended command to summarize which files have been\n> > modified, which files have been marked for commit, and which remain\n> > untracked?\n\ngit-gui? ;-)\n\nI also use the following two aliases:\n\n [alias]\n dw = diff --stat --summary\n di = diff --stat --summary --cached\n\n...\n> I do not make partial commits myself, so\n> distinction between staged and unstaged are not something I am\n> usually interested in.\n\nI never used to either. Then git-gui got really useful at showing\nthe distinction and I started using the index for a staging ground.\nI almost never make partial commits, unless it is completely trivial,\ne.g. a comment fixup that isn't related to what I'm really doing\nbut that was too darn obvious to not fix _right now_.\n\nBut I always toss things into the index when I've read through the\ndiff a few times and am very happy with it. I may not be done with\nthe overall commit, but I park the hunks into the index so I don't\nhave to look at them again. I use a trackball so \"tossing into the\nindex\" is really just a flick of the wrist to select the menu item\nfrom the pop-up menu on that hunk. Quite like a toss. ;-)\n\nI tend to test only once I have everything staged into the index and\nmy working directory is clean (nothing changed that isn't staged).\nIts at that point that I think my change is done and I'm happy with\nhow the diff looks. Usually the code is correct at this point too;\nbut if its not I'll fix it, then commit.\n\n\nSo where does that leave me regarding the touched but not changed\nfiles? Usually they just get in my way in the end. I don't much\ncare that I've undone the file back to what I had in the index.\nIt just doesn't provide any value to my workflow. It is actually\nincredible rare that I cause it to happen too. Usually I won't\nwrite the file back to disk if I'm just going to undo it.\n\nIf I do write it to disk I'm likely to stage it or at least some\nhunks of it. If I later change my mind and undo those changes I'm\ngoing to effectively stage the reverse difference. This is a very\nnice hint showing me that yes in fact the older way was better.\n\nPersonally? The index is a killer feature for me. Totally.\nI can't work without it anymore, it has become a total crutch to me.\nYou would have to pry the index from my cold dead fingers to get\nme to stop using it.\n\nYea, that is a total about-face for me. I used to think the index\nwas only useful for merges. Boy was I wrong!\n\n-- \nShawn.\n"},{"id":"49566","messageId":"7vir7xngfs.fsf@assigned-by-dhcp.cox.net","threadId":"9342","inReplyTo":"20070803082435.GA15475@coredump.intra.peff.net","subject":"Re: git-diff on touched files: bug or feature?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-08-03T08:57:43Z","receivedAt":"2007-08-03T08:57:43Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> Without making a partial commit, how would you split the\n> bugfix changes from the working changes? Or do you manually\n> pull the bugfix into another branch or working tree?\n\nI typically stash the WIP away with \"git diff HEAD >P.diff &&\ngit reset --hard\" (I should learn to use \"git stash\" these\ndays), and switch to an appropriate branch for bugfix (if it is\ngenerally applicable) or stay on the branch (if it is a fix-up\nfor an earlier patch for the topic) to work on the fix. Then\nunstash to continue where I left off.\n\n> In your workflow, how do you\n> remind yourself that there are untracked files that need to be added? Do\n> you just wait until you see the commit template at the end?\n\nI do not leave files that need to be added untracked for a long\ntime. Also, I tend to be picky about making sure that (1)\nthings build from scratch, and that (2) \"make clean\" removes all\ncrufts. Because of this, I run \"make clean\" followed by \"git\nclean -n\" more often than other people. The latter picks them\nup if I forget to add them when I created them.\n"},{"id":"49570","messageId":"7vvebxm156.fsf@assigned-by-dhcp.cox.net","threadId":"9342","inReplyTo":"20070803084010.GM20052@spearce.org","subject":"Re: git-diff on touched files: bug or feature?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-08-03T09:13:25Z","receivedAt":"2007-08-03T09:13:25Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Shawn O. Pearce\" writes:\n\n>> I do not make partial commits myself, so\n>> distinction between staged and unstaged are not something I am\n>> usually interested in.\n>\n> I never used to either. Then git-gui got really useful at showing\n> the distinction and I started using the index for a staging ground.\n\nI guess we are saying the same thing. I do use index for\nstaging large-ish changes. I simply do not care about the\nstaged/not-staged distinction in the sense that \"I still haven't\nstaged these, that's good because these do not belong to the\ncommit I am going to make next\".\n\nOutput from \"git diff\" being truly empty is the cue that such a\nlarge-ish worktree change is ready to be committed, and the\nfinal \"git diff --cached\" would give me the full picture. A\nsmall-ish change won't make \"git diff\" in the middle empty, but\nchecking the final \"git diff --cached\" before committing is the\nsame.\n"},{"id":"49574","messageId":"Pine.LNX.4.64.0708031121000.14781@racer.site","threadId":"9342","inReplyTo":"7v3az1qgdg.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Add --show-touched option to show \"diff --git\" line when contents are unchanged","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-08-03T10:23:21Z","receivedAt":"2007-08-03T10:23:21Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 2 Aug 2007, Junio C Hamano wrote:\n\n> Steven Grimm writes:\n> \n> > \tOkay, enough arguing about whether the empty diff lines are\n> > \tuseful or not -- here's a patch to get rid of them.\n> \n> I do not think this addresses anything but -p (i.e. textual\n> diff) output. If we _were_ to really do this, I think the patch\n> I sent earlier today, with possible improvements I suggested,\n> would be a better direction to go.\n\nBut I'd really think that what should be done (if anything has to be done \nat all) is to introduce a config variable which triggers the same logic in \ngit-diff as was introduced in 2b5f9a8c0cff511f2bb0833b1ee02645b79323f4.\n\nCiao,\nDscho\n"},{"id":"49626","messageId":"7vir7wmk84.fsf@assigned-by-dhcp.cox.net","threadId":"9342","inReplyTo":"Pine.LNX.4.64.0708031121000.14781@racer.site","subject":"Re: [PATCH] Add --show-touched option to show \"diff --git\" line when contents are unchanged","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-08-03T20:33:31Z","receivedAt":"2007-08-03T20:33:31Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> But I'd really think that what should be done (if anything has to be done \n> at all) is to introduce a config variable which triggers the same logic in \n> git-diff as was introduced in 2b5f9a8c0cff511f2bb0833b1ee02645b79323f4.\n\nSorry, I don't follow at all. The diff toolchain works all\ninside core without having to write a temporary index out, which\nwas the issue the commit you are quoting was about.\n\nIn any case, enough discussion. Here is an updated patch, which\nI _could_ be pursuaded to consider for inclusion after v1.5.3\nhappens, if there are enough agreements and Acks.\n\n-- >8 --\ngit-diff: --stat-unmatch\n\nTraditionally, git-diff with the working tree files showed files\nwhose lstat(2) information did not match with what were recorded\nin the index, even if the actual contents did not have any\ndifferences. This squelches such output from git-diff by\ndefault.\n\nA new option, --stat-unmatch, is introduced to restore the\ntraditional behaviour. This is useful to see if you want to\nknow you have too many files you only touch(1)ed without\nmodifying. Having many such paths hurts performance, and you\ncan run \"git-update-index --refresh\" to update the lstat(2)\ninformation recorded in the index in such a case.\n\nThe low level git-diff-files command is not affected.\n\nSigned-off-by: Junio C Hamano \n---\n\n Documentation/git-diff.txt | 13 ++++++++++\n builtin-diff.c | 13 ++++++++++\n diff.c | 54 ++++++++++++++++++++++++++++++++++++++++++++\n diff.h | 1 +\n 4 files changed, 81 insertions(+), 0 deletions(-)\n\ndiff --git a/Documentation/git-diff.txt b/Documentation/git-diff.txt\nindex b36e705..efdc65b 100644\n--- a/Documentation/git-diff.txt\n+++ b/Documentation/git-diff.txt\n@@ -59,6 +59,19 @@ OPTIONS\n -------\n include::diff-options.txt[]\n \n+--stat-unmatch::\n+\tTraditionally, `git-diff` with the working tree files\n+\tshowed files whose `lstat(2)` information did not match\n+\twith what were recorded in the index, even if the actual\n+\tcontents did not have any differences, but recent git\n+\tsquelches such output. This option can be used to\n+\trestore the traditional behaviour. This is useful to\n+\tsee if you want to know you have too many files you only\n+\t`touch(1)`ed without modifying. Having many such paths\n+\thurts performance, and you can run `git-update-index\n+\t--refresh` to update the `lstat(2)` information recorded\n+\tin the index in such a case.\n+\n ...::\n \tThe parameters, when given, are used to limit\n \tthe diff to the named paths (you can give directory\ndiff --git a/builtin-diff.c b/builtin-diff.c\nindex b48121e..c8e137d 100644\n--- a/builtin-diff.c\n+++ b/builtin-diff.c\n@@ -222,6 +222,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 \n \tif (!setup_diff_no_index(&rev, argc, argv, nongit, prefix))\n \t\targc = 0;\n@@ -338,5 +339,17 @@ int cmd_diff(int argc, const char **argv, const char *prefix)\n \t\t\t\t\t ent, ents);\n \tif (rev.diffopt.exit_with_status)\n \t\tresult = rev.diffopt.has_changes;\n+\n+\t/*\n+\t * We do not actually do this here because 99% of the time\n+\t * the pager is in effect and this will not be shown, but\n+\t * you could if you wanted to.\n+\t *\n+\t * if (1 < rev.diffopt.skip_stat_unmatch)\n+\t *\tfprintf(stderr,\n+\t *\t\t\"Squelched %d stat-only differences.\\n\",\n+\t *\t\trev.diffopt.skip_stat_unmatch - 1);\n+\t *\n+\t */\n \treturn result;\n }\ndiff --git a/diff.c b/diff.c\nindex a5fc56b..8c26e4d 100644\n--- a/diff.c\n+++ b/diff.c\n@@ -2261,6 +2261,8 @@ int diff_opt_parse(struct diff_options *options, const char **av, int ac)\n \telse if (!strcmp(arg, \"--shortstat\")) {\n \t\toptions->output_format |= DIFF_FORMAT_SHORTSTAT;\n \t}\n+\telse if (!strcmp(arg, \"--stat-unmatch\"))\n+\t\toptions->skip_stat_unmatch = 0;\n \telse if (!prefixcmp(arg, \"--stat\")) {\n \t\tchar *end;\n \t\tint width = options->stat_width;\n@@ -3143,11 +3145,63 @@ static void diffcore_apply_filter(const char *filter)\n \t*q = outq;\n }\n \n+static void diffcore_skip_stat_unmatch(struct diff_options *diffopt)\n+{\n+\tint i;\n+\tstruct diff_queue_struct *q = &diff_queued_diff;\n+\tstruct diff_queue_struct outq;\n+\toutq.queue = NULL;\n+\toutq.nr = outq.alloc = 0;\n+\n+\tfor (i = 0; i < q->nr; i++) {\n+\t\tstruct diff_filepair *p = q->queue[i];\n+\n+\t\t/*\n+\t\t * 1. Entries that come from stat info dirtyness\n+\t\t * always have both sides (iow, not create/delete),\n+\t\t * one side of the object name is unknown, with\n+\t\t * the same mode and size. Keep the ones that\n+\t\t * do not match these criteria. They have real\n+\t\t * differences.\n+\t\t *\n+\t\t * 2. At this point, the file is known to be modified,\n+\t\t * with the same mode and size, and the object\n+\t\t * name of one side is unknown. Need to inspect\n+\t\t * the identical contents.\n+\t\t */\n+\t\tif (!DIFF_FILE_VALID(p->one) || /* (1) */\n+\t\t !DIFF_FILE_VALID(p->two) ||\n+\t\t (p->one->sha1_valid && p->two->sha1_valid) ||\n+\t\t (p->one->mode != p->two->mode) ||\n+\t\t diff_populate_filespec(p->one, 1) ||\n+\t\t diff_populate_filespec(p->two, 1) ||\n+\t\t (p->one->size != p->two->size) ||\n+\n+\t\t diff_populate_filespec(p->one, 0) || /* (2) */\n+\t\t diff_populate_filespec(p->two, 0) ||\n+\t\t memcmp(p->one->data, p->two->data, p->one->size))\n+\t\t\tdiff_q(&outq, p);\n+\t\telse {\n+\t\t\t/*\n+\t\t\t * The caller can subtract 1 from skip_stat_unmatch\n+\t\t\t * to determine how many paths were dirty only\n+\t\t\t * due to stat info mismatch.\n+\t\t\t */\n+\t\t\tdiffopt->skip_stat_unmatch++;\n+\t\t\tdiff_free_filepair(p);\n+\t\t}\n+\t}\n+\tfree(q->queue);\n+\t*q = outq;\n+}\n+\n void diffcore_std(struct diff_options *options)\n {\n \tif (options->quiet)\n \t\treturn;\n \n+\tif (options->skip_stat_unmatch && !options->find_copies_harder)\n+\t\tdiffcore_skip_stat_unmatch(options);\n \tif (options->break_opt != -1)\n \t\tdiffcore_break(options->break_opt);\n \tif (options->detect_rename)\ndiff --git a/diff.h b/diff.h\nindex 9fd6d44..de21f8e 100644\n--- a/diff.h\n+++ b/diff.h\n@@ -65,6 +65,7 @@ struct diff_options {\n \tint context;\n \tint break_opt;\n \tint detect_rename;\n+\tint skip_stat_unmatch;\n \tint line_termination;\n \tint output_format;\n \tint pickaxe_opts;\n"},{"id":"49635","messageId":"vpqps24i9sx.fsf@bauges.imag.fr","threadId":"9342","inReplyTo":"7vir7wmk84.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Add --show-touched option to show \"diff --git\" line when contents are unchanged","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2007-08-03T21:32:14Z","receivedAt":"2007-08-03T21:32:14Z","isPatch":true,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Junio C Hamano writes:\n\n> Johannes Schindelin writes:\n>\n>> But I'd really think that what should be done (if anything has to be done \n>> at all) is to introduce a config variable which triggers the same logic in \n>> git-diff as was introduced in 2b5f9a8c0cff511f2bb0833b1ee02645b79323f4.\n>\n> Sorry, I don't follow at all. The diff toolchain works all\n> inside core without having to write a temporary index out, which\n> was the issue the commit you are quoting was about.\n>\n> In any case, enough discussion. Here is an updated patch, which\n> I _could_ be pursuaded to consider for inclusion after v1.5.3\n> happens, if there are enough agreements and Acks.\n\nTo me, that patch makes sense, yes.\n\nThat said, a configuration option would probably be better than a\ncommand-line option. The expected behavior seems to depend on user,\nbut not much on use-cases. So, people who like the old behavior could\nset the option and forget about it, and other would not be distracted\nabout it.\n\nAlso, is there any particular reason not to update the index stat\ninformation when files are found to be identical? Well, we've\ndiscussed that quite much in this thread, but this is what status is\ndoing, and I still fail to see why diff shouldn't. (I can update the\npatch myself if you agree it should be done. I don't know the git\ncodebase well, so it takes time for me, but the exercise is fun ;-) )\n\nSide performance note: if I understand your patch correctly, you're\ncomparing the file content twice for actually modified changes. But\nthat probably doesn't matter much since the expansive thing is to load\nthe files and to compute the diff.\n\nThanks,\n\n-- \nMatthieu\n"},{"id":"49637","messageId":"7v1wekmgo8.fsf@assigned-by-dhcp.cox.net","threadId":"9342","inReplyTo":"vpqps24i9sx.fsf@bauges.imag.fr","subject":"Re: [PATCH] Add --show-touched option to show \"diff --git\" line when contents are unchanged","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-08-03T21:50:15Z","receivedAt":"2007-08-03T21:50:15Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy writes:\n\n> Also, is there any particular reason not to update the index stat\n> information when files are found to be identical?\n\nVery much --- diff is a read-only operation.\n\n\"git-status $args\" on the other hand is a preview of \"what would\nhappen if I say 'git-commit $args'\", and in order to compute\nthat, you would fundamentally need to be able to write into the\nobject store. In a special case of giving empty $args it can be\nread-only. The commit Dscho quoted earlier was to hack that\naround so that \"git-status\" can pretend to be a read-only\noperation in a repository you do not have write permission to.\n"},{"id":"49638","messageId":"vpqir7wi5oc.fsf@bauges.imag.fr","threadId":"9342","inReplyTo":"7v1wekmgo8.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Add --show-touched option to show \"diff --git\" line when contents are unchanged","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2007-08-03T23:01:23Z","receivedAt":"2007-08-03T23:01:23Z","isPatch":true,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Junio C Hamano writes:\n\n> Matthieu Moy writes:\n>\n>> Also, is there any particular reason not to update the index stat\n>> information when files are found to be identical?\n>\n> Very much --- diff is a read-only operation.\n>\n> \"git-status $args\" on the other hand is a preview of \"what would\n> happen if I say 'git-commit $args'\", and in order to compute\n> that, you would fundamentally need to be able to write into the\n> object store. In a special case of giving empty $args it can be\n> read-only.\n\nCan you give an example where it _could_ not be read-only?\n\n> The commit Dscho quoted earlier was to hack that around so that\n> \"git-status\" can pretend to be a read-only operation in a repository\n> you do not have write permission to.\n\nI really, really, really, don't understand your argument.\n\nThere are two different concepts:\n\n* Should git-diff be \"read-only for the user\"?\n (i.e. external specification)\n\n* Should git-diff be actually read-only for the filesystem?\n (i.e. implementation)\n\n\n\"read-only for the user\" is a user-interface thing. It just means that\nrunning\n\n$ git-diff >& /dev/null; whatever\n\nwill give the same result as\n\n$ whatever\n\nIn another context, \"cat\", for example, is a read-only operation for\nthe user. I can run \"cat whatever-file\" without influencing the\nbehavior of subsequent operations. Now, somewhere in the kernel of my\nOS, I do hope that reading this file will have side-effects (putting\nthe file in the cache, and why not decide to physically move the file\non disk).\n\n\nHere, obviously, git-diff is a read-only operation for the user. I\ndon't expect git-diff to modify the behavior of subsequent commands,\nbut I appreciate if git-diff can improve the speed of subsequent\ncommands.\n\nNow, both of us agree that git-status should not be read-only for the\nfilesystem, both of us agree that git-diff should be read-only for the\nuser, but we disagree on the two other cases.\n\nIn the same way, I expect git-status to be read-only for the user. You\nsay \"what _would_ happen _if_ I say commit $args\". But you don't\ncommit, the sentence is conditionnal. I don't expect any tool to have\nvisible side-effects when I say \"what would happen if ...\".\n\n-- \nMatthieu\n"},{"id":"49642","messageId":"7vlkcskx5z.fsf@assigned-by-dhcp.cox.net","threadId":"9342","inReplyTo":"vpqir7wi5oc.fsf@bauges.imag.fr","subject":"Re: [PATCH] Add --show-touched option to show \"diff --git\" line when contents are unchanged","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-08-03T23:36:56Z","receivedAt":"2007-08-03T23:36:56Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy writes:\n\nMatthieu Moy writes:\n\n>> \"git-status $args\" on the other hand is a preview of \"what would\n>> happen if I say 'git-commit $args'\", and in order to compute\n>> that, you would fundamentally need to be able to write into the\n>> object store. In a special case of giving empty $args it can be\n>> read-only.\n>\n> Can you give an example where it _could_ not be read-only?\n\nThink of what \"git commit -a\" would have to do. It needs to\nhash and deposit a new object for blobs that have been\nmodified. Where do those new blob object go?\n\n> In the same way, I expect git-status to be read-only for the user. You\n> say \"what _would_ happen _if_ I say commit $args\". But you don't\n> commit, the sentence is conditionnal. I don't expect any tool to have\n> visible side-effects when I say \"what would happen if ...\".\n\nBy running git-status the user is asking to get the overall\npicture, discarding the \"touched but not modified\" information.\nOnce you _HAVE TO_ refresh the index for whatever reason, it is\nbetter to keep the result of the effort and cycles spent for\nthat refresh operation for obvious performance reasons in\npractice, and that is what we have now in git-status. IOW, we\nare practical bunch.\n\nMaybe in a theoretical ideal world, you might prefer to\nreverting back to the stat-dirty original index to make\ngit-status appear a read-only operation, with continued degraded\nperformance. You are welcome to reimplement it that way, and\nthe patch should be trivial (while git-commit.sh is still a\nscript, at least) but that is not what we did.\n"},{"id":"49932","messageId":"vpqr6mhahtx.fsf@bauges.imag.fr","threadId":"9342","inReplyTo":"7vlkcskx5z.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Add --show-touched option to show \"diff --git\" line when contents are unchanged","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2007-08-05T19:42:50Z","receivedAt":"2007-08-05T19:42:50Z","isPatch":true,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Junio C Hamano writes:\n\n> Matthieu Moy writes:\n>\n>>> \"git-status $args\" on the other hand is a preview of \"what would\n>>> happen if I say 'git-commit $args'\", and in order to compute\n>>> that, you would fundamentally need to be able to write into the\n>>> object store. In a special case of giving empty $args it can be\n>>> read-only.\n>>\n>> Can you give an example where it _could_ not be read-only?\n>\n> Think of what \"git commit -a\" would have to do.\n\nI don't know whether it was a typo, but we're not talking about\n\"commit\", but \"status\".\n\n> It needs to hash and deposit a new object for blobs that have been\n> modified. Where do those new blob object go?\n\ngit-status _does_ hash and deposit new objects, but it doesn't _need_\nto. It can very well show you what \"commit -a\" would do without\nactually doing it.\n\nA trivial (and very stupid, yes) way to do this would be\n\ncp -r . /tmp/git/\ncd /tmp/git\ngit-status -a\n\nThere's no visible side-effects for the user.\n\nIIRC, git-status -a does actually \"git-add\" the modified objects, but\ndoes so in a temporary index, so I believe the objects you leave in\nthe objects database are not pointed to by anyone (indeed, I just\nchecked, git-fsck --unreachable shows the dangling blob), and are not\nreally useful (but will probably be used later when you run commit or\nadd).\n\n> Maybe in a theoretical ideal world, you might prefer to\n> reverting back to the stat-dirty original index to make\n> git-status appear a read-only operation, with continued degraded\n> performance. You are welcome to reimplement it that way, and\n> the patch should be trivial (while git-commit.sh is still a\n> script, at least) but that is not what we did.\n\nYou still didn't understand my point about the difference between\nuser-specification and internal behavior. I'm very happy with\ngit-status updating the stat information in the index, since it is not\nsuppose to have user-visible side effects (it has with the current\nempty-diff-for-touched-files behavior of git-diff).\n\nNow, at that point, if I still didn't manage to show you the\ndifference between user-visible behavior and implementation, I believe\nI have no better thing to do than giving up.\n\n-- \nMatthieu\n"},{"id":"49934","messageId":"Pine.LNX.4.64.0708052044570.14781@racer.site","threadId":"9342","inReplyTo":"vpqr6mhahtx.fsf@bauges.imag.fr","subject":"Re: [PATCH] Add --show-touched option to show \"diff --git\" line when contents are unchanged","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-08-05T19:45:54Z","receivedAt":"2007-08-05T19:45:54Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 5 Aug 2007, Matthieu Moy wrote:\n\n> Junio C Hamano writes:\n> \n> > Matthieu Moy writes:\n> >\n> >>> \"git-status $args\" on the other hand is a preview of \"what would\n> >>> happen if I say 'git-commit $args'\", and in order to compute\n> >>> that, you would fundamentally need to be able to write into the\n> >>> object store. In a special case of giving empty $args it can be\n> >>> read-only.\n> >>\n> >> Can you give an example where it _could_ not be read-only?\n> >\n> > Think of what \"git commit -a\" would have to do.\n> \n> I don't know whether it was a typo, but we're not talking about\n> \"commit\", but \"status\".\n\nNo typo. \"git status\" is literally \"git commit --dry-run\". Why? Because \npeople expected it to be called \"git status\".\n\nAnd even if I think about it over and over again, it makes sense.\n\nCiao,\nDscho\n"},{"id":"49937","messageId":"vpqlkcpah60.fsf@bauges.imag.fr","threadId":"9342","inReplyTo":"Pine.LNX.4.64.0708052044570.14781@racer.site","subject":"Re: [PATCH] Add --show-touched option to show \"diff --git\" line when contents are unchanged","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2007-08-05T19:57:11Z","receivedAt":"2007-08-05T19:57:11Z","isPatch":true,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Johannes Schindelin writes:\n\n>> I don't know whether it was a typo, but we're not talking about\n>> \"commit\", but \"status\".\n>\n> No typo. \"git status\" is literally \"git commit --dry-run\". Why? Because \n> people expected it to be called \"git status\".\n>\n> And even if I think about it over and over again, it makes sense.\n\nI was surprised of that when looking at the source, but yes, it makes\nsense.\n\nBut the message I was replying to claimed that \n\"git status-or-commit -a\" _needed_ to put objects in the object\ndatabase. That's true of \"git commit -a\" but not of \"git status -a\",\neven if you call it \"git commit --dry-run -a\", precisely because of\nthe --dry-run thing.\n\n-- \nMatthieu\n"},{"id":"50026","messageId":"20070806155622.GA21448@moooo.ath.cx","threadId":"9342","inReplyTo":"7vir7wmk84.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Add --show-touched option to show \"diff --git\" line when contents are unchanged","fromName":"Matthias Lederhofer","fromEmail":"matled@gmx.net","sentAt":"2007-08-06T15:56:22Z","receivedAt":"2007-08-06T15:56:22Z","isPatch":true,"sender":{"key":"matled@gmx.net","avatar":null},"body":"Junio C Hamano wrote:\n> In any case, enough discussion. Here is an updated patch, which\n> I _could_ be pursuaded to consider for inclusion after v1.5.3\n> happens, if there are enough agreements and Acks.\n\nI like this new behaviour but I don't see the old one too often\neither.\n"},{"id":"50028","messageId":"86bqdkbq59.fsf@lola.quinscape.zz","threadId":"9342","inReplyTo":"7vir7wmk84.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Add --show-touched option to show \"diff --git\" line when contents are unchanged","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-08-06T16:10:10Z","receivedAt":"2007-08-06T16:10:10Z","isPatch":true,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Junio C Hamano writes:\n\n> Johannes Schindelin writes:\n>\n>> But I'd really think that what should be done (if anything has to be done \n>> at all) is to introduce a config variable which triggers the same logic in \n>> git-diff as was introduced in 2b5f9a8c0cff511f2bb0833b1ee02645b79323f4.\n>\n> Sorry, I don't follow at all. The diff toolchain works all\n> inside core without having to write a temporary index out, which\n> was the issue the commit you are quoting was about.\n>\n> In any case, enough discussion. Here is an updated patch, which\n> I _could_ be pursuaded to consider for inclusion after v1.5.3\n> happens, if there are enough agreements and Acks.\n\nAck, ack, ack. The current default behavior is plainly unusable. For\nexample, I've rsynced -a a tree including .git, and suddenly git-diff\ngoes out of kilter. And stops doing so when running git-status once.\n\nThis is the worst kind of \"unpredictable\", and I don't care one bit\nthat there are conceivable use cases.\n\nI don't even think it prudent to _offer_ the --show-touched option in\na porcelain such as git-diff as long as purportedly read-only\nporcelain commands like git-status can trash the state: what is\nreported is not actually \"touched\" but something internal to the\noperation of git.\n\nAt least not without a notice in the manual that this option might or\nmight not work, depending on what one did previously.\n\n-- \nDavid Kastrup\n"},{"id":"50030","messageId":"864pjcbpud.fsf@lola.quinscape.zz","threadId":"9342","inReplyTo":"86bqdkbq59.fsf@lola.quinscape.zz","subject":"Re: [PATCH] Add --show-touched option to show \"diff --git\" line when contents are unchanged","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-08-06T16:16:42Z","receivedAt":"2007-08-06T16:16:42Z","isPatch":true,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"\nDavid Kastrup writes:\n\n> I don't even think it prudent to _offer_ the --show-touched option\n> in a porcelain such as git-diff as long as purportedly read-only\n> porcelain commands like git-status can trash the state: what is\n> reported is not actually \"touched\" but something internal to the\n> operation of git.\n>\n> At least not without a notice in the manual that this option might\n> or might not work, depending on what one did previously.\n\nProposal: if this option is to stay, call it rather --show-stale since\nthat corresponds better with what the option actually does: show\nwhether git's inode cache went stale. It does _not_ show whether the\nfile has been touched (git-status does not touch files, for example).\n\n-- \nDavid Kastrup\n"},{"id":"50040","messageId":"vpqr6mgwhsf.fsf@bauges.imag.fr","threadId":"9342","inReplyTo":"86bqdkbq59.fsf@lola.quinscape.zz","subject":"Re: [PATCH] Add --show-touched option to show \"diff --git\" line when contents are unchanged","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2007-08-06T20:05:04Z","receivedAt":"2007-08-06T20:05:04Z","isPatch":true,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"David Kastrup writes:\n\n> Ack, ack, ack. The current default behavior is plainly unusable. For\n> example, I've rsynced -a a tree including .git, and suddenly git-diff\n> goes out of kilter. And stops doing so when running git-status\n> once.\n\nUnfortunately, the patch solves the \"large and irrelevant output\" of\ngit-diff, but not the performance problem (see the rest of the thread,\nI failed to convince Junio that updating the index was a performance\nimprovement while keeping the same user semantics).\n\n-- \nMatthieu\n"},{"id":"50042","messageId":"7vodhkbdx2.fsf@assigned-by-dhcp.cox.net","threadId":"9342","inReplyTo":"vpqr6mgwhsf.fsf@bauges.imag.fr","subject":"Re: [PATCH] Add --show-touched option to show \"diff --git\" line when contents are unchanged","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-08-06T20:34:17Z","receivedAt":"2007-08-06T20:34:17Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy writes:\n\n> Unfortunately, the patch solves the \"large and irrelevant output\" of\n> git-diff, but not the performance problem (see the rest of the thread,\n> I failed to convince Junio that updating the index was a performance\n> improvement while keeping the same user semantics).\n\nThat's what update-index --refresh (or status if you insist) are\nfor, and the coalmine canary you are so dead set to kill are\nhelping you realize the need for running.\n"},{"id":"50086","messageId":"alpine.LFD.0.999.0708062118190.5037@woody.linux-foundation.org","threadId":"9342","inReplyTo":"20070803053717.GA16379@midwinter.com","subject":"Re: [PATCH] Add --show-touched option to show \"diff --git\" line when contents are unchanged","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-08-07T04:22:26Z","receivedAt":"2007-08-07T04:22:26Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 2 Aug 2007, Steven Grimm wrote:\n>\n> The default is now to not show the diff --git header line if the file's\n> timestamp has changed but the contents and/or file mode haven't.\n\nI don't mind this per se, but I'd *really* want some kind of warning that \nthe index is not up-to-date.\n\nOtherwise, git usage can be horrendously slow, and you're never even told \nwhy. The diffs just take lots of time (because it reads each file), but \nthe output is empty.\n\n> \tPersonally I'm in favor of doing away with the option altogether\n> \tand having the code always work the way it works by default with\n> \tthis patch, but if some people find the old behavior useful they\n> \tcan still get at it with the new option.\n\nIt's not that the old output is \"useful\" in itself, but it's important for \npeople to know that the index is clean. So I'd suggest just setting a flag \nwhen the header isn't printed, and then printing out a single line at the \nend about \"git index not up-to-date\" or something.\n\nDoing a \"git diff\" cannot actually update the index (since it very much \nhas to work on a read-only setup too), which is why the index _stays_ \nstale unless something is done (eg \"git status\") to refresh it. And it's \nthat stale index that continues to make for bad performance without any \nindication of why that is a problem.\n\n\t\t\tLinus\n"},{"id":"50087","messageId":"7v4pjc9czm.fsf@assigned-by-dhcp.cox.net","threadId":"9342","inReplyTo":"alpine.LFD.0.999.0708062118190.5037@woody.linux-foundation.org","subject":"Re: [PATCH] Add --show-touched option to show \"diff --git\" line when contents are unchanged","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-08-07T04:37:17Z","receivedAt":"2007-08-07T04:37:17Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> It's not that the old output is \"useful\" in itself, but it's important for \n> people to know that the index is clean. So I'd suggest just setting a flag \n> when the header isn't printed, and then printing out a single line at the \n> end about \"git index not up-to-date\" or something.\n\nThat's essentially the patch I sent out in another thread allows\nyou to do, and some of these people even Acked them, but there\nis one minor issue. \"git diff\" output is paged, and that \"not\nup to date\" warning, if it is given to stderr, would not be\nusually seen.\n\n> Doing a \"git diff\" cannot actually update the index (since it very much \n> has to work on a read-only setup too), which is why the index _stays_ \n> stale unless something is done (eg \"git status\") to refresh it. And it's \n> that stale index that continues to make for bad performance without any \n> indication of why that is a problem.\n\nIndeed.\n\nAt least, I am now glad to know that somebody else is of the\nsame opinion as I am.\n"},{"id":"50090","messageId":"46B80993.3080409@midwinter.com","threadId":"9342","inReplyTo":"alpine.LFD.0.999.0708062118190.5037@woody.linux-foundation.org","subject":"Re: [PATCH] Add --show-touched option to show \"diff --git\" line when contents are unchanged","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2007-08-07T05:56:35Z","receivedAt":"2007-08-07T05:56:35Z","isPatch":true,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"Linus Torvalds wrote:\n> It's not that the old output is \"useful\" in itself, but it's important for \n> people to know that the index is clean. So I'd suggest just setting a flag \n> when the header isn't printed, and then printing out a single line at the \n> end about \"git index not up-to-date\" or something.\n> \n\nOr even a count of the number of files whose index data is unclean. I'd \nbe fine with that as a suffix to the diff output.\n\n> Doing a \"git diff\" cannot actually update the index (since it very much \n> has to work on a read-only setup too), which is why the index _stays_ \n> stale unless something is done (eg \"git status\") to refresh it. And it's \n> that stale index that continues to make for bad performance without any \n> indication of why that is a problem.\n> \n\nI totally agree that there needs to be a way to tell if the index is \nclean or not. I do wonder if the default output of \"git diff\" is the \nright place for that information, but if the notification can be \ncollapsed to a line or two (rather than the unbounded number of lines \nthat it potentially outputs now) then that's probably good enough.\n\nActually, though this will probably make people roll their eyes, before \nthis discussion I would have guessed that \"git status\" would be the \ncommand that would tell you the index was out of date, and that there'd \nbe a separate command (say, \"git update-index\"?) that you could then use \nto sync things up again. The fact that \"git status\" is really \"git \nupdate index a little bit then show status\" was not something I \nexpected; it presents itself as a query utility, not an update utility, \nso I would have expected it to be read-only. Its index-modifying \nbehavior is not even hinted at in the documentation (a patch for which \nfollows.)\n\n-Steve\n"},{"id":"50091","messageId":"20070807055747.GA27417@midwinter.com","threadId":"9342","inReplyTo":"46B80993.3080409@midwinter.com","subject":"[PATCH] Add a note about the index being updated by git-status in some cases","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2007-08-07T05:57:47Z","receivedAt":"2007-08-07T05:57:47Z","isPatch":true,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"Signed-off-by: Steven Grimm \n---\n Documentation/git-status.txt | 7 +++++++\n 1 files changed, 7 insertions(+), 0 deletions(-)\n\ndiff --git a/Documentation/git-status.txt b/Documentation/git-status.txt\nindex 6f16eb0..8fd0fc6 100644\n--- a/Documentation/git-status.txt\n+++ b/Documentation/git-status.txt\n@@ -27,6 +27,13 @@ The command takes the same set of options as `git-commit`; it\n shows what would be committed if the same options are given to\n `git-commit`.\n \n+If any paths have been touched in the working tree (that is,\n+their modification times have changed) but their contents and\n+permissions are identical to those in the index file, the command\n+updates the index file. Running `git-status` can thus speed up\n+subsequent operations such as `git-diff` if the working tree\n+contains many paths that have been touched but not modified.\n+\n \n OUTPUT\n ------\n-- \n1.5.3.rc2.4.g726f9\n"},{"id":"50093","messageId":"86k5s7am7c.fsf@lola.quinscape.zz","threadId":"9342","inReplyTo":"7vodhkbdx2.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Add --show-touched option to show \"diff --git\" line when contents are unchanged","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-08-07T06:32:55Z","receivedAt":"2007-08-07T06:32:55Z","isPatch":true,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Junio C Hamano writes:\n\n> Matthieu Moy writes:\n>\n>> Unfortunately, the patch solves the \"large and irrelevant output\"\n>> of git-diff, but not the performance problem (see the rest of the\n>> thread, I failed to convince Junio that updating the index was a\n>> performance improvement while keeping the same user semantics).\n>\n> That's what update-index --refresh (or status if you insist) are\n> for, and the coalmine canary you are so dead set to kill are helping\n> you realize the need for running.\n\nThat does not convince me. Cache staleness should be a problem of\ngit, not of the user. In particular if the user is just using\nporcelain. If letting the cache get stale impacts performance, then\ngit should clean up its act on its own without barfing when using\nunrelated commands. If it notices this during diff (presumably by\noverstepping some staleness ratio), then it can set a \"regenerate on\nnext opportunity\" flag on the index, and then the next command wanting\nto process the index from the start can rewrite a refreshed version.\n\n-- \nDavid Kastrup\n"},{"id":"50095","messageId":"20070807063523.GA29617@midwinter.com","threadId":"9342","inReplyTo":"46B80993.3080409@midwinter.com","subject":"[PATCH] git-diff: Output a warning about stale files in the index","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2007-08-07T06:35:23Z","receivedAt":"2007-08-07T06:35:23Z","isPatch":true,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"Signed-off-by: Steven Grimm \n---\n\tThis is based on (and includes) Junio's patch. This should\n\thopefully address the \"I want to know when my index is very\n\tstale\" problem with both his original patch and mine.\n\n\tIf we are running a pager, I output the warning to standard\n\toutput so it doesn't get immediately scrolled off the screen by\n\tthe paged diff output. Otherwise I output to standard error\n\twhich is really the more appropriate place for the warning.\n\tObviously that is no good if the user is running his own pager,\n\tbut I'm not sure how to detect that and not cause problems for\n\tdiffs that are piped into other programs.\n\n diff.c | 59 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++---\n diffcore.h | 1 +\n 2 files changed, 57 insertions(+), 3 deletions(-)\n\ndiff --git a/diff.c b/diff.c\nindex a5fc56b..7b11195 100644\n--- a/diff.c\n+++ b/diff.c\n@@ -2979,7 +2979,7 @@ int diff_flush_patch_id(struct diff_options *options, unsigned char *sha1)\n \n \tfree(q->queue);\n \tq->queue = NULL;\n-\tq->nr = q->alloc = 0;\n+\tq->nr = q->alloc = q->removed = 0;\n \n \treturn result;\n }\n@@ -3015,6 +3015,17 @@ void diff_flush(struct diff_options *options)\n \tint i, output_format = options->output_format;\n \tint separator = 0;\n \n+\tif (q->removed > 0 && ! (output_format & DIFF_FORMAT_NO_OUTPUT)) {\n+\t\tchar *format = \"Warning: %d %s touched but not modified. \"\n+\t\t\t \"Consider running git-status.\\n\";\n+\t\tchar *plural = q->removed == 1 ? \"path\" : \"paths\";\n+\n+\t\tif (pager_in_use)\n+\t\t\tprintf(format, q->removed, plural);\n+\t\telse\n+\t\t\tfprintf(stderr, format, q->removed, plural);\n+\t}\n+\n \t/*\n \t * Order: raw, stat, summary, patch\n \t * or: name/name-status/checkdiff (other bits clear)\n@@ -3084,7 +3095,7 @@ void diff_flush(struct diff_options *options)\n free_queue:\n \tfree(q->queue);\n \tq->queue = NULL;\n-\tq->nr = q->alloc = 0;\n+\tq->nr = q->alloc = q->removed = 0;\n }\n \n static void diffcore_apply_filter(const char *filter)\n@@ -3093,7 +3104,7 @@ static void diffcore_apply_filter(const char *filter)\n \tstruct diff_queue_struct *q = &diff_queued_diff;\n \tstruct diff_queue_struct outq;\n \toutq.queue = NULL;\n-\toutq.nr = outq.alloc = 0;\n+\toutq.nr = outq.alloc = outq.removed = 0;\n \n \tif (!filter)\n \t\treturn;\n@@ -3143,6 +3154,47 @@ static void diffcore_apply_filter(const char *filter)\n \t*q = outq;\n }\n \n+static void diffcore_remove_empty(void)\n+{\n+\tint i;\n+\tstruct diff_queue_struct *q = &diff_queued_diff;\n+\tstruct diff_queue_struct outq;\n+\toutq.queue = NULL;\n+\toutq.nr = outq.alloc = outq.removed = 0;\n+\n+\tfor (i = 0; i < q->nr; i++) {\n+\t\tstruct diff_filepair *p = q->queue[i];\n+\n+\t\t/*\n+\t\t * 1. Keep the ones that cannot be diff-files\n+\t\t * \"false\" match that are only queued due to\n+\t\t * cache dirtyness.\n+\t\t *\n+\t\t * 2. Modified, same size and mode, and the object\n+\t\t * name of one side is unknown. If they do not\n+\t\t * have identical contents, keep them.\n+\t\t * They are different.\n+\t\t */\n+\t\tif ((p->status != DIFF_STATUS_MODIFIED) || /* (1) */\n+\t\t (p->one->sha1_valid && p->two->sha1_valid) ||\n+\t\t (p->one->mode != p->two->mode) ||\n+\n+\t\t diff_populate_filespec(p->one, 1) || /* (2) */\n+\t\t diff_populate_filespec(p->two, 1) ||\n+\t\t (p->one->size != p->two->size) ||\n+\t\t diff_populate_filespec(p->one, 0) ||\n+\t\t diff_populate_filespec(p->two, 0) ||\n+\t\t memcmp(p->one->data, p->two->data, p->one->size))\n+\t\t\tdiff_q(&outq, p);\n+\t\telse {\n+\t\t\tdiff_free_filepair(p);\n+\t\t\toutq.removed++;\n+\t\t}\n+\t}\n+\tfree(q->queue);\n+\t*q = outq;\n+}\n+\n void diffcore_std(struct diff_options *options)\n {\n \tif (options->quiet)\n@@ -3160,6 +3212,7 @@ void diffcore_std(struct diff_options *options)\n \t\tdiffcore_order(options->orderfile);\n \tdiff_resolve_rename_copy();\n \tdiffcore_apply_filter(options->filter);\n+\tdiffcore_remove_empty();\n \n \toptions->has_changes = !!diff_queued_diff.nr;\n }\ndiff --git a/diffcore.h b/diffcore.h\nindex eef17c4..e5a9244 100644\n--- a/diffcore.h\n+++ b/diffcore.h\n@@ -81,6 +81,7 @@ struct diff_queue_struct {\n \tstruct diff_filepair **queue;\n \tint alloc;\n \tint nr;\n+\tint removed;\n };\n \n extern struct diff_queue_struct diff_queued_diff;\n-- \n1.5.3.rc2.4.g726f9\n"},{"id":"50096","messageId":"46B813A0.4040305@midwinter.com","threadId":"9342","inReplyTo":"alpine.LFD.0.999.0708062118190.5037@woody.linux-foundation.org","subject":"Re: [PATCH] Add --show-touched option to show \"diff --git\" line when contents are unchanged","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2007-08-07T06:39:28Z","receivedAt":"2007-08-07T06:39:28Z","isPatch":true,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"Linus Torvalds wrote:\n> Doing a \"git diff\" cannot actually update the index (since it very much \n> has to work on a read-only setup too), which is why the index _stays_ \n> stale unless something is done (eg \"git status\") to refresh it. \n\nAnother thought: How about if git-diff *tries* to update the index if \nneeded, but failure to do so is not treated as an error condition? That \nseems like the best of both worlds to me: git would self-correct a \npotential performance problem without user intervention, while still \nworking properly in a read-only environment.\n\n-Steve\n"},{"id":"50097","messageId":"86d4xzaltr.fsf@lola.quinscape.zz","threadId":"9342","inReplyTo":"7v4pjc9czm.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Add --show-touched option to show \"diff --git\" line when contents are unchanged","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-08-07T06:41:04Z","receivedAt":"2007-08-07T06:41:04Z","isPatch":true,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Junio C Hamano writes:\n\n> Linus Torvalds writes:\n>\n>> Doing a \"git diff\" cannot actually update the index (since it very\n>> much has to work on a read-only setup too), which is why the index\n>> _stays_ stale unless something is done (eg \"git status\") to refresh\n>> it. And it's that stale index that continues to make for bad\n>> performance without any indication of why that is a problem.\n>\n> Indeed.\n>\n> At least, I am now glad to know that somebody else is of the same\n> opinion as I am.\n\nI don't want a system to tell me when it is shooting itself in the\nfoot. It should not be doing this in the first place.\n\nFile systems have automatic fsck procedures enforced regularly, too,\nto keep them operative. If git finds that it is getting inefficient,\nit should just mark the index as \"regenerate at next access\". And\nthen do it.\n\n-- \nDavid Kastrup\n"},{"id":"50098","messageId":"7vbqdj9709.fsf@assigned-by-dhcp.cox.net","threadId":"9342","inReplyTo":"20070807063523.GA29617@midwinter.com","subject":"Re: [PATCH] git-diff: Output a warning about stale files in the index","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-08-07T06:46:30Z","receivedAt":"2007-08-07T06:46:30Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Steven Grimm writes:\n\n> Signed-off-by: Steven Grimm \n> ---\n> \tThis is based on (and includes) Junio's patch. This should\n> \thopefully address the \"I want to know when my index is very\n> \tstale\" problem with both his original patch and mine.\n>\n> \tIf we are running a pager, I output the warning to standard\n> \toutput so it doesn't get immediately scrolled off the screen by\n> \tthe paged diff output. Otherwise I output to standard error\n> \twhich is really the more appropriate place for the warning.\n> \tObviously that is no good if the user is running his own pager,\n> \tbut I'm not sure how to detect that and not cause problems for\n> \tdiffs that are piped into other programs.\n\nHmph. One way to avoid causing problems for diffs that are\npiped into other programs and still give the \"index of sync\"\nwarning is to emit \"diff --git\" line and no patch body fot\ntextual diffs, or 0{40} SHA-1 on the right hand side for --raw\nformat diffs.\n\nJokes aside...\n\nFor textual diffs, I think we can always spit out the warning\nmessage at the beginning of at the end on the standard output\nwithout harming any of the patch based toolchain.\n\nSo how about...\n\n - If and only if the output format asks for textual diff\n (DIFF_FORMAT_PATCH), we do this \"stat-dirty-removal\";\n otherwise we do not spend extra cycles and keep the current\n behaviour.\n\n - At the end of patch text, show \"stat-dirty-removal\" warning\n on stdout.\n"},{"id":"50099","messageId":"vpqfy2vu9gn.fsf@bauges.imag.fr","threadId":"9342","inReplyTo":"alpine.LFD.0.999.0708062118190.5037@woody.linux-foundation.org","subject":"Re: [PATCH] Add --show-touched option to show \"diff --git\" line when contents are unchanged","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2007-08-07T06:47:52Z","receivedAt":"2007-08-07T06:47:52Z","isPatch":true,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Linus Torvalds writes:\n\n> It's not that the old output is \"useful\" in itself, but it's important for \n> people to know that the index is clean. So I'd suggest just setting a flag \n> when the header isn't printed, and then printing out a single line at the \n> end about \"git index not up-to-date\" or something.\n\nYes. Junio's patch has this as a comment, it's probably good to\nuncomment it, and perhaps print it directly on stdout so that you see\nit even with a pager.\n\n> Doing a \"git diff\" cannot actually update the index (since it very much \n> has to work on a read-only setup too),\n\nErr, what's the relationship between the two parts of your sentence?\nYou can't be sure that git-diff will update the index (because you may\nbe working on a read-only setup, yes), but git-diff can at least _try_\nto, and fall-back to the read-only behavior if updating the index\nfails.\n\nThat's not a highly original idea since this is what git already does\nwith \"status\".\n\nOnce more, I'm willing to write the code for that if it has a chance\nto be accepted.\n\n-- \nMatthieu\n"},{"id":"50100","messageId":"20070807071712.GA32751@midwinter.com","threadId":"9342","inReplyTo":"7vbqdj9709.fsf@assigned-by-dhcp.cox.net","subject":"[PATCH v2] git-diff: Output a warning about stale files in the index","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2007-08-07T07:17:12Z","receivedAt":"2007-08-07T07:17:12Z","isPatch":true,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"Signed-off-by: Steven Grimm \n---\n\tModified as suggested by Junio.\n\n diff.c | 55 ++++++++++++++++++++++++++++++++++++++++++++++++++++---\n diffcore.h | 1 +\n 2 files changed, 53 insertions(+), 3 deletions(-)\n\ndiff --git a/diff.c b/diff.c\nindex a5fc56b..5f2e1fe 100644\n--- a/diff.c\n+++ b/diff.c\n@@ -2979,7 +2979,7 @@ int diff_flush_patch_id(struct diff_options *options, unsigned char *sha1)\n \n \tfree(q->queue);\n \tq->queue = NULL;\n-\tq->nr = q->alloc = 0;\n+\tq->nr = q->alloc = q->removed = 0;\n \n \treturn result;\n }\n@@ -3074,6 +3074,12 @@ void diff_flush(struct diff_options *options)\n \t\t\tif (check_pair_status(p))\n \t\t\t\tdiff_flush_patch(p, options);\n \t\t}\n+\n+\t\tif (q->removed > 0) {\n+\t\t\tprintf(\"Warning: %d %s touched but not modified. \"\n+\t\t\t \"Consider running git-status.\\n\",\n+\t\t\t q->removed, q->removed == 1 ? \"path\" : \"paths\");\n+\t\t}\n \t}\n \n \tif (output_format & DIFF_FORMAT_CALLBACK)\n@@ -3084,7 +3090,7 @@ void diff_flush(struct diff_options *options)\n free_queue:\n \tfree(q->queue);\n \tq->queue = NULL;\n-\tq->nr = q->alloc = 0;\n+\tq->nr = q->alloc = q->removed = 0;\n }\n \n static void diffcore_apply_filter(const char *filter)\n@@ -3093,7 +3099,7 @@ static void diffcore_apply_filter(const char *filter)\n \tstruct diff_queue_struct *q = &diff_queued_diff;\n \tstruct diff_queue_struct outq;\n \toutq.queue = NULL;\n-\toutq.nr = outq.alloc = 0;\n+\toutq.nr = outq.alloc = outq.removed = 0;\n \n \tif (!filter)\n \t\treturn;\n@@ -3143,6 +3149,47 @@ static void diffcore_apply_filter(const char *filter)\n \t*q = outq;\n }\n \n+static void diffcore_remove_empty(void)\n+{\n+\tint i;\n+\tstruct diff_queue_struct *q = &diff_queued_diff;\n+\tstruct diff_queue_struct outq;\n+\toutq.queue = NULL;\n+\toutq.nr = outq.alloc = outq.removed = 0;\n+\n+\tfor (i = 0; i < q->nr; i++) {\n+\t\tstruct diff_filepair *p = q->queue[i];\n+\n+\t\t/*\n+\t\t * 1. Keep the ones that cannot be diff-files\n+\t\t * \"false\" match that are only queued due to\n+\t\t * cache dirtyness.\n+\t\t *\n+\t\t * 2. Modified, same size and mode, and the object\n+\t\t * name of one side is unknown. If they do not\n+\t\t * have identical contents, keep them.\n+\t\t * They are different.\n+\t\t */\n+\t\tif ((p->status != DIFF_STATUS_MODIFIED) || /* (1) */\n+\t\t (p->one->sha1_valid && p->two->sha1_valid) ||\n+\t\t (p->one->mode != p->two->mode) ||\n+\n+\t\t diff_populate_filespec(p->one, 1) || /* (2) */\n+\t\t diff_populate_filespec(p->two, 1) ||\n+\t\t (p->one->size != p->two->size) ||\n+\t\t diff_populate_filespec(p->one, 0) ||\n+\t\t diff_populate_filespec(p->two, 0) ||\n+\t\t memcmp(p->one->data, p->two->data, p->one->size))\n+\t\t\tdiff_q(&outq, p);\n+\t\telse {\n+\t\t\tdiff_free_filepair(p);\n+\t\t\toutq.removed++;\n+\t\t}\n+\t}\n+\tfree(q->queue);\n+\t*q = outq;\n+}\n+\n void diffcore_std(struct diff_options *options)\n {\n \tif (options->quiet)\n@@ -3160,6 +3207,8 @@ void diffcore_std(struct diff_options *options)\n \t\tdiffcore_order(options->orderfile);\n \tdiff_resolve_rename_copy();\n \tdiffcore_apply_filter(options->filter);\n+\tif (options->output_format & DIFF_FORMAT_PATCH)\n+\t\tdiffcore_remove_empty();\n \n \toptions->has_changes = !!diff_queued_diff.nr;\n }\ndiff --git a/diffcore.h b/diffcore.h\nindex eef17c4..e5a9244 100644\n--- a/diffcore.h\n+++ b/diffcore.h\n@@ -81,6 +81,7 @@ struct diff_queue_struct {\n \tstruct diff_filepair **queue;\n \tint alloc;\n \tint nr;\n+\tint removed;\n };\n \n extern struct diff_queue_struct diff_queued_diff;\n-- \n1.5.3.rc2.4.g726f9\n"},{"id":"50101","messageId":"7vbqdj7poi.fsf@assigned-by-dhcp.cox.net","threadId":"9342","inReplyTo":"20070807071712.GA32751@midwinter.com","subject":"Re: [PATCH v2] git-diff: Output a warning about stale files in the index","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-08-07T07:46:05Z","receivedAt":"2007-08-07T07:46:05Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Steven Grimm writes:\n\n> Signed-off-by: Steven Grimm \n> ---\n> \tModified as suggested by Junio.\n\nOkay.\n\nAssuming that other people are happy with this version (I have\nto warn you that I haven't even attempted to apply this patch,\nlet alone compiling yet), I'd prefer to keep our combined\nthought process in the commit log, so that we do not have to\nrehash this later, over and over again.\n\nSomething along the following lines, perhaps...?\n\n After starting to edit a working tree file but later when your\n edit ends up identical to the original (this can also happen\n when you ran a wholesale regexp replace with something like\n \"perl -i\" that does not touch many of the paths), \"git diff\"\n between the index and the working tree outputs many \"empty\"\n diffs that show \"diff --git\" header and nothing else, because\n these paths are stat dirty. While it was _a_ way to warn the\n user that the earlier action of the user made the index\n ineffective as an optimization mechanism, it was felt too loud\n for the purpose of warning even to experienced users, and also\n resulted in confusing people new to git.\n\n This replaces the \"empty\" diffs with a single warning message\n at the end. When you see such a message, you know you did\n something suboptimal to your index; you can optimize the index\n again by running \"git-update-index --refresh\".\n\n The change affects only \"git diff\" that outputs patch text,\n because that is where the annoyance of too many \"empty\" diff\n is most strongly felt, and because the warning message can be\n safely ignored by downstream tools without getting mistaken as\n part of the patch. For the low-level \"git diff-files\", the\n traditional behaviour is retained.\n"},{"id":"50102","messageId":"46B82471.4090001@midwinter.com","threadId":"9342","inReplyTo":"7vbqdj7poi.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH v2] git-diff: Output a warning about stale files in the index","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2007-08-07T07:51:13Z","receivedAt":"2007-08-07T07:51:13Z","isPatch":true,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"Junio C Hamano wrote:\n> Something along the following lines, perhaps...?\n> \n\nThat seems like a fine commit message to me. My one-liner definitely \nassumed too much context, coming in the middle of this discussion as it \ndid -- much better to be explicit about the reasoning for posterity's sake.\n\n-Steve\n"},{"id":"50107","messageId":"f99cj0$41v$1@sea.gmane.org","threadId":"9342","inReplyTo":"7vbqdj7poi.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH v2] git-diff: Output a warning about stale files in the index","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-08-07T09:04:33Z","receivedAt":"2007-08-07T09:04:33Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n>   After starting to edit a working tree file but later when your\n>   edit ends up identical to the original (this can also happen\n>   when you ran a wholesale regexp replace with something like\n>   \"perl -i\" that does not touch many of the paths),\n\nDoes touch the file (makes file stat-dirty, changes file mtime),\nbut doesn't change it.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"50126","messageId":"20070807133458.GA19834@fieldses.org","threadId":"9342","inReplyTo":"86k5s7am7c.fsf@lola.quinscape.zz","subject":"Re: [PATCH] Add --show-touched option to show \"diff --git\" line when contents are unchanged","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2007-08-07T13:34:58Z","receivedAt":"2007-08-07T13:34:58Z","isPatch":true,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Tue, Aug 07, 2007 at 08:32:55AM +0200, David Kastrup wrote:\n> Junio C Hamano writes:\n> \n> > Matthieu Moy writes:\n> >\n> >> Unfortunately, the patch solves the \"large and irrelevant output\"\n> >> of git-diff, but not the performance problem (see the rest of the\n> >> thread, I failed to convince Junio that updating the index was a\n> >> performance improvement while keeping the same user semantics).\n> >\n> > That's what update-index --refresh (or status if you insist) are\n> > for, and the coalmine canary you are so dead set to kill are helping\n> > you realize the need for running.\n> \n> That does not convince me. Cache staleness should be a problem of\n> git, not of the user. In particular if the user is just using\n> porcelain. If letting the cache get stale impacts performance, then\n> git should clean up its act on its own without barfing when using\n> unrelated commands. If it notices this during diff (presumably by\n> overstepping some staleness ratio), then it can set a \"regenerate on\n> next opportunity\" flag on the index, and then the next command wanting\n> to process the index from the start can rewrite a refreshed version.\n\nThe last time I had a serious problem with \"cache staleness\", it was\nwith Beagle, which modifies the files it indexes (by writing some\nextended attributes). I figured out what was happening when I noticed\nthat the list of touched files was growing each time I did a diff\n(implying the something was working on them right then), so I ran top,\nnoticed beagled, eventually thought to query the extended attributes,\nand finally turned off beagled's indexing to solve the problem.\n\nSo, in this case:\n\n\t- If git had fixed up the problem silently, I probably would\n\t have just assumed git was slow and not found the problem.\n\n\t- Seeing the actual list of files for which the index was dirty\n\t helped me identify the problem. I probably would have\n\t eventually figured it out even if all I'd had was a single\n\t \"index is stale\" message, but I suspect it would have taken\n\t longer.\n\nDraw whatever moral you'd like....\n\n--b.\n"},{"id":"50165","messageId":"alpine.LFD.0.999.0708072004150.23971@woody.linux-foundation.org","threadId":"9342","inReplyTo":"7v4pjc9czm.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Add --show-touched option to show \"diff --git\" line when contents are unchanged","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-08-08T03:07:08Z","receivedAt":"2007-08-08T03:07:08Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n[ Slow at responding to email, sorry ]\n\nOn Mon, 6 Aug 2007, Junio C Hamano wrote:\n> \n> That's essentially the patch I sent out in another thread allows\n> you to do, and some of these people even Acked them, but there\n> is one minor issue. \"git diff\" output is paged, and that \"not\n> up to date\" warning, if it is given to stderr, would not be\n> usually seen.\n\nI agree. I wouldn't send it to stderr, I'd literally make it part of the \noutput.\n\nEverybody who takes patches will accept crud afterwards, since the normal \nthing is to email them around, so there's no real downside to adding some \nstatus output at the end. It shouldn't screw anything up, but people will \nhopefully notice (sure, if you exit the pager without looking at it all \nyou wouldn't notice, but that's _already_ true, so..)\n\n\t\tLinus\n"},{"id":"50166","messageId":"alpine.LFD.0.999.0708072040160.25146@woody.linux-foundation.org","threadId":"9342","inReplyTo":"46B80993.3080409@midwinter.com","subject":"Re: [PATCH] Add --show-touched option to show \"diff --git\" line when contents are unchanged","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-08-08T03:42:13Z","receivedAt":"2007-08-08T03:42:13Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 7 Aug 2007, Steven Grimm wrote:\n> \n> Actually, though this will probably make people roll their eyes, before this\n> discussion I would have guessed that \"git status\" would be the command that\n> would tell you the index was out of date, and that there'd be a separate\n> command (say, \"git update-index\"?) that you could then use to sync things up\n> again.\n\nWell, historically, you literally would just do\n\n\tgit update-index --refresh\n\nto do that.\n\n\"git status\" is fairly newfangled, and is purely because users from other \nSCM's expected that kind of command to exist. The fact that as part of it \nrunning it does that update-index is really just a side effect.\n\n\t\tLinus\n"},{"id":"50167","messageId":"7vabt2667l.fsf@assigned-by-dhcp.cox.net","threadId":"9342","inReplyTo":"alpine.LFD.0.999.0708072004150.23971@woody.linux-foundation.org","subject":"Re: [PATCH] Add --show-touched option to show \"diff --git\" line when contents are unchanged","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-08-08T03:44:14Z","receivedAt":"2007-08-08T03:44:14Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> Everybody who takes patches will accept crud afterwards, since the normal \n> thing is to email them around, so there's no real downside to adding some \n> status output at the end. It shouldn't screw anything up, but people will \n> hopefully notice (sure, if you exit the pager without looking at it all \n> you wouldn't notice, but that's _already_ true, so..)\n\nWell, at least \"hundreds of empty diff\" has a value of getting\nattention for even such a use case, so you _could_ argue this\npatch is a regression ;-)\n\nIn any case, this will go in as part of the first batch after\n1.5.3, I would guess.\n"},{"id":"50176","messageId":"Pine.LNX.4.64.0708080923580.14781@racer.site","threadId":"9342","inReplyTo":"alpine.LFD.0.999.0708072004150.23971@woody.linux-foundation.org","subject":"Re: [PATCH] Add --show-touched option to show \"diff --git\" line when contents are unchanged","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-08-08T08:26:58Z","receivedAt":"2007-08-08T08:26:58Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 7 Aug 2007, Linus Torvalds wrote:\n\n> Everybody who takes patches will accept crud afterwards, since the \n> normal thing is to email them around, so there's no real downside to \n> adding some status output at the end. It shouldn't screw anything up, \n> but people will hopefully notice (sure, if you exit the pager without \n> looking at it all you wouldn't notice, but that's _already_ true, so..)\n\nBut then, you could output the message _twice_: first possibly in-between \npatches (\"WARNING: ...\") and then at the end.\n\nHowever, I have the slight suspicion that people will not even notice. I \nmean, we had bug reports on merge-recursive, where the reporter failed to \neven acknowledge the fact that merge-recursive said that there were \nconflicts, and even listed them.\n\nSo I have the slight suspicion that all this will accomplish is \"shut the \ndarn thing up\", and old-timers will have a harder time, since they no \nlonger spot easily when they did a Dumb Thing and left the index out of \nsync.\n\nSlightly negative.\n\nCiao,\nDscho\n"},{"id":"50178","messageId":"7v3ayu5scj.fsf@assigned-by-dhcp.cox.net","threadId":"9342","inReplyTo":"Pine.LNX.4.64.0708080923580.14781@racer.site","subject":"Re: [PATCH] Add --show-touched option to show \"diff --git\" line when contents are unchanged","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-08-08T08:43:40Z","receivedAt":"2007-08-08T08:43:40Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> So I have the slight suspicion that all this will accomplish is \"shut the \n> darn thing up\", and old-timers will have a harder time, since they no \n> longer spot easily when they did a Dumb Thing and left the index out of \n> sync.\n\nThe hardest hit would be old-timers who try to be friendly by\ntrying to help new people, who has much less chance to notice\nand report these much less prominent warnings, over e-mail or\nirc.\n"},{"id":"50181","messageId":"86abt25qyw.fsf@lola.quinscape.zz","threadId":"9342","inReplyTo":"7v3ayu5scj.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Add --show-touched option to show \"diff --git\" line when contents are unchanged","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-08-08T09:13:27Z","receivedAt":"2007-08-08T09:13:27Z","isPatch":true,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Junio C Hamano writes:\n\n> Johannes Schindelin writes:\n>\n>> So I have the slight suspicion that all this will accomplish is \"shut the \n>> darn thing up\", and old-timers will have a harder time, since they no \n>> longer spot easily when they did a Dumb Thing and left the index out of \n>> sync.\n>\n> The hardest hit would be old-timers who try to be friendly by\n> trying to help new people, who has much less chance to notice\n> and report these much less prominent warnings, over e-mail or\n> irc.\n\n\"Dude, you got a stale index hanging out of your trousers.\"\n\nI find it ridiculous to parade local problems in patches sent out to\nthe world rather than fixing them, so that old-timers have a chance to\nget karma points.\n\nReally: if stale indexes are considered a problem, git should silently\nmark the staleness in the file, and the next time (or after three more\ntimes or whatever) the index is used, it is silently regenerated.\n\nOld-timers can get an option disabling this so that they can proud\nthemselves on cleaning up after themselves consciously, but for the\nnormal user, this is a bother he can do without.\n\n-- \nDavid Kastrup\n"},{"id":"50184","messageId":"Pine.LNX.4.64.0708081022440.14781@racer.site","threadId":"9342","inReplyTo":"7v3ayu5scj.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Add --show-touched option to show \"diff --git\" line when contents are unchanged","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-08-08T09:23:12Z","receivedAt":"2007-08-08T09:23:12Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 8 Aug 2007, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > So I have the slight suspicion that all this will accomplish is \"shut the \n> > darn thing up\", and old-timers will have a harder time, since they no \n> > longer spot easily when they did a Dumb Thing and left the index out of \n> > sync.\n> \n> The hardest hit would be old-timers who try to be friendly by\n> trying to help new people, who has much less chance to notice\n> and report these much less prominent warnings, over e-mail or\n> irc.\n\nTrue. It is even bigger than that annoyance to people who know how git \nworks.\n\nCiao,\nDscho\n"},{"id":"50185","messageId":"f9c44o$gqs$1@sea.gmane.org","threadId":"9342","inReplyTo":"Pine.LNX.4.64.0708081022440.14781@racer.site","subject":"Re: [PATCH] Add --show-touched option to show \"diff --git\" line when contents are unchanged","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-08-08T09:58:49Z","receivedAt":"2007-08-08T09:58:49Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Johannes Schindelin wrote:\n\n> On Wed, 8 Aug 2007, Junio C Hamano wrote:\n> \n>> Johannes Schindelin writes:\n>> \n>>> So I have the slight suspicion that all this will accomplish is \"shut the \n>>> darn thing up\", and old-timers will have a harder time, since they no \n>>> longer spot easily when they did a Dumb Thing and left the index out of \n>>> sync.\n>> \n>> The hardest hit would be old-timers who try to be friendly by\n>> trying to help new people, who has much less chance to notice\n>> and report these much less prominent warnings, over e-mail or\n>> irc.\n> \n> True. It is even bigger than that annoyance to people who know how git \n> works.\n\nPerhaps config variable, by default old behaviour if not set?\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"50497","messageId":"7vzm0xltru.fsf@assigned-by-dhcp.cox.net","threadId":"9342","inReplyTo":"20070807071712.GA32751@midwinter.com","subject":"Re: [PATCH v2] git-diff: Output a warning about stale files in the index","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-08-11T20:07:33Z","receivedAt":"2007-08-11T20:07:33Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Actually this is wrong in two points:\n\n * The filtering should be done upfront at the beginning of the\n diffcore_std(), not before the end. Otherwise, unchanged but\n cache dirty file could be subject to copy detection.\n\n * I do not think it should affect the low-level git-diff-* (or\n you should update the tests, documentations and perhaps\n whatever people can find from google).\n\nBy the way, I had an updated version of my patch to fix the\nfirst point on 'pu' for a while.\n"}]}