{"thread":{"id":"31672","subject":"Git diff-file bug?","startedAt":"2012-09-28T18:55:10Z","lastAt":"2012-10-03T11:58:15Z","messageCount":18,"participants":["Scott Batchelor","Junio C Hamano","Jeff King","Andreas Schwab","Paul Mackerras","Jonathan Nieder","Drew Northup"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"200133","messageId":"CAEkqydxRy3ukSWyQ53Tiosq+DMWWLG=AVuZk+Jm79Y5SaRmeDw@mail.gmail.com","threadId":"31672","inReplyTo":null,"subject":"Git diff-file bug?","fromName":"Scott Batchelor","fromEmail":"scott.batchelor@gmail.com","sentAt":"2012-09-28T18:55:10Z","receivedAt":"2012-09-28T18:55:10Z","isPatch":false,"sender":{"key":"scott.batchelor@gmail.com","avatar":null},"body":"Hello.\nI'm fairly new to git and am witnessing some strange behavior with git\nthat I suspect may be a bug. Can anyone set my mind at rest.\n\nEvery so often (I've not quite figured out the exact set of\ncircumstances yet) \"git diff-files\" shows that every file in my repo\nis modified, when I expect none to be. If I type \"git status\" (which\nshows what I expect - no files modified) and then \"git diff-files\"\nagain, git now shows that no files have been modified (which is what I\nexpect). It's like \"git status\" is resetting something that \"git\ndiff-files\" uses.\n\nI'm trying to figure out what the problem with \"git diff-files\" is\nbecause gitk uses it under the hood, and I think that gitk is\nreporting erroneous changes (which are also reset by performing a\n\"git status\" in the repo) in the \"patch\" files list.\n\nAny thoughts? I'm using git 1.7.11.4 on SLES 10.3.\n\nThanks,\nScott.\n"},{"id":"200138","messageId":"20120928202330.GA5770@sigill.intra.peff.net","threadId":"31672","inReplyTo":"CAEkqydxRy3ukSWyQ53Tiosq+DMWWLG=AVuZk+Jm79Y5SaRmeDw@mail.gmail.com","subject":"Re: Git diff-file bug?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-09-28T20:23:30Z","receivedAt":"2012-09-28T20:23:30Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Sep 28, 2012 at 07:55:10PM +0100, Scott Batchelor wrote:\n\n> I'm fairly new to git and am witnessing some strange behavior with git\n> that I suspect may be a bug. Can anyone set my mind at rest.\n\nIt's not a bug.\n\n> Every so often (I've not quite figured out the exact set of\n> circumstances yet) \"git diff-files\" shows that every file in my repo\n> is modified, when I expect none to be.\n\nDiff-files only looks at the cached sha1 in the index. It will not\nre-read the file to update its index entry if its stat information\nappears out of date. So what is happening is that another program[1] is\nupdating the timestamp or other information about each file, but not the\ncontent. Diff-files does not re-read the content to find out there is in\nfact no change.\n\nIf you are using plumbing like diff-files, you are expected to run \"git\nupdate-index --refresh\" yourself first. The reasoning is that for\nperformance reasons, a script that issues many git commands would only\nwant to pay the price to refresh the index once, at the beginning of the\nscript.\n\nIf you use the \"git diff\" porcelain, it will automatically refresh the\nindex for you.\n\n> If I type \"git status\" (which shows what I expect - no files modified)\n> and then \"git diff-files\" again, git now shows that no files have been\n> modified (which is what I expect). It's like \"git status\" is resetting\n> something that \"git diff-files\" uses.\n\nExactly. \"git status\" automatically refreshes the index, and the result\nis saved.\n\n> I'm trying to figure out what the problem with \"git diff-files\" is\n> because gitk uses it under the hood, and I think that gitk is\n> reporting erroneous changes (which are also reset by performing a\n> \"git status\" in the repo) in the \"patch\" files list.\n\ngitk should probably be calling \"update-index --refresh\" on startup. If\nit already is, then it may be that whatever is updating the files is\ndoing it while gitk is running.\n\n-Peff\n\n[1] Usually stat updates are caused by another program. But we have had\n cases where unusual filesystems yielded inconsistent results from\n stat().\n"},{"id":"200135","messageId":"7vr4plkhin.fsf@alter.siamese.dyndns.org","threadId":"31672","inReplyTo":"CAEkqydxRy3ukSWyQ53Tiosq+DMWWLG=AVuZk+Jm79Y5SaRmeDw@mail.gmail.com","subject":"Re: Git diff-file bug?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-09-28T20:40:48Z","receivedAt":"2012-09-28T20:40:48Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Scott Batchelor writes:\n\n> I'm fairly new to git and am witnessing some strange behavior with git\n> that I suspect may be a bug. Can anyone set my mind at rest.\n>\n> Every so often (I've not quite figured out the exact set of\n> circumstances yet) \n\nFigure that circumstances out. That is the key to the issue.\nSomething in your workflow is futzing with the inode data of the\nfiles in your working tree behind your back. It sometimes is a\nvirus scanner.\n\n\"git diff-*\" plumbing commands are meant to be used after running\n\"git update-index --refresh\" once in the program and when the caller\nof these commands (in your case, gitk) knows that any change in the\ninformation returned by lstat(2) on the paths in the working tree\nfiles since that call indicate real changes to the files.\n\n\"git status\" internally runs an equivalent of \"--refresh\" before it\ngoes to find changes, so after running it, until that something\nsmudges the inode data behind your back, \"gitk\" will not be\nconfused.\n"},{"id":"200136","messageId":"20120928205054.GA5985@sigill.intra.peff.net","threadId":"31672","inReplyTo":"20120928202330.GA5770@sigill.intra.peff.net","subject":"[PATCH] gitk: refresh the index before running diff-files","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-09-28T20:50:54Z","receivedAt":"2012-09-28T20:50:54Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Sep 28, 2012 at 04:23:30PM -0400, Jeff King wrote:\n\n> > I'm trying to figure out what the problem with \"git diff-files\" is\n> > because gitk uses it under the hood, and I think that gitk is\n> > reporting erroneous changes (which are also reset by performing a\n> > \"git status\" in the repo) in the \"patch\" files list.\n> \n> gitk should probably be calling \"update-index --refresh\" on startup. If\n> it already is, then it may be that whatever is updating the files is\n> doing it while gitk is running.\n\nAh, it is not refreshing the index at all. Try this (substitute\nMakefile with some file in your repository):\n\n $ touch Makefile\n $ gitk <-- reports uncommitted changes\n $ git update-index --refresh\n $ gitk <-- changes go away\n\nI am not a tcl hacker, but the patch below seems to fix it for me.\n\n-- >8 --\nSubject: [PATCH] gitk: refresh the index before running diff-files\n\nIf you have index entries that are stat-dirty but otherwise\nunchanged, gitk will erroneously report that \"local\nuncommited changes\" are present. This is because we call the\nplumbing diff-files, which expects us to have updated the\nindex ourselves. So let's start doing so.\n\nWe only run this once per invocation of gitk, though. The\npoint of diff-files not running the update is that it does\nnot need to be run for every command, but generally only\nonce per high-level operation.\n\nSigned-off-by: Jeff King \n---\nPotentially the \"reload\" command should reset the need_index_refresh\nflag, too.\n\n gitk | 10 ++++++++++\n 1 file changed, 10 insertions(+)\n\ndiff --git a/gitk b/gitk\nindex 379582a..561be23 100755\n--- a/gitk\n+++ b/gitk\n@@ -5112,6 +5112,14 @@ proc dodiffindex {} {\n filerun $fd [list readdiffindex $fd $lserial $i]\n }\n \n+proc refresh_index {} {\n+ global need_index_refresh\n+ if { $need_index_refresh } {\n+\texec sh -c \"git update-index --refresh >/dev/null 2>&1 || true\"\n+\tset need_index_refresh false\n+ }\n+}\n+\n proc readdiffindex {fd serial inst} {\n global viewmainheadid nullid nullid2 curview commitinfo commitdata lserial\n global vfilelimit\n@@ -5131,6 +5139,7 @@ proc readdiffindex {fd serial inst} {\n }\n \n # now see if there are any local changes not checked in to the index\n+ refresh_index\n set cmd \"|git diff-files\"\n if {$vfilelimit($curview) ne {}} {\n \tset cmd [concat $cmd -- $vfilelimit($curview)]\n@@ -11670,6 +11679,7 @@ set want_ttk 1\n set autosellen 40\n set perfile_attrs 0\n set want_ttk 1\n+set need_index_refresh true\n \n if {[tk windowingsystem] eq \"aqua\"} {\n set extdifftool \"opendiff\"\n-- \n1.7.12.42.g8bdb6d3\n"},{"id":"200137","messageId":"7vmx09keqp.fsf@alter.siamese.dyndns.org","threadId":"31672","inReplyTo":"20120928205054.GA5985@sigill.intra.peff.net","subject":"Re: [PATCH] gitk: refresh the index before running diff-files","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-09-28T21:40:46Z","receivedAt":"2012-09-28T21:40:46Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> Potentially the \"reload\" command should reset the need_index_refresh\n> flag, too.\n\nYeah, I think that is a sane enhancement to think about.\n\n> gitk | 10 ++++++++++\n> 1 file changed, 10 insertions(+)\n>\n> diff --git a/gitk b/gitk\n> index 379582a..561be23 100755\n> --- a/gitk\n> +++ b/gitk\n> @@ -5112,6 +5112,14 @@ proc dodiffindex {} {\n> filerun $fd [list readdiffindex $fd $lserial $i]\n> }\n> \n> +proc refresh_index {} {\n> + global need_index_refresh\n> + if { $need_index_refresh } {\n> +\texec sh -c \"git update-index --refresh >/dev/null 2>&1 || true\"\n> +\tset need_index_refresh false\n> + }\n> +}\n> +\n> proc readdiffindex {fd serial inst} {\n> global viewmainheadid nullid nullid2 curview commitinfo commitdata lserial\n> global vfilelimit\n> @@ -5131,6 +5139,7 @@ proc readdiffindex {fd serial inst} {\n> }\n> \n> # now see if there are any local changes not checked in to the index\n> + refresh_index\n> set cmd \"|git diff-files\"\n> if {$vfilelimit($curview) ne {}} {\n> \tset cmd [concat $cmd -- $vfilelimit($curview)]\n> @@ -11670,6 +11679,7 @@ set want_ttk 1\n> set autosellen 40\n> set perfile_attrs 0\n> set want_ttk 1\n> +set need_index_refresh true\n> \n> if {[tk windowingsystem] eq \"aqua\"} {\n> set extdifftool \"opendiff\"\n"},{"id":"200139","messageId":"m24nmh4x1t.fsf@igel.home","threadId":"31672","inReplyTo":"20120928205054.GA5985@sigill.intra.peff.net","subject":"Re: [PATCH] gitk: refresh the index before running diff-files","fromName":"Andreas Schwab","fromEmail":"schwab@linux-m68k.org","sentAt":"2012-09-28T22:11:58Z","receivedAt":"2012-09-28T22:11:58Z","isPatch":true,"sender":{"key":"schwab@linux-m68k.org","avatar":"https://avatars.githubusercontent.com/u/2175493?v=4"},"body":"Jeff King writes:\n\n> +proc refresh_index {} {\n> + global need_index_refresh\n> + if { $need_index_refresh } {\n> +\texec sh -c \"git update-index --refresh >/dev/null 2>&1 || true\"\n\nI think the usual idiom for ignoring errors is to use catch around exec,\navoiding the extra shell wrapper:\n\n catch { exec git update-index --refresh }\n\nAndreas.\n\n-- \nAndreas Schwab, schwab@linux-m68k.org\nGPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5\n\"And now for something completely different.\"\n"},{"id":"200140","messageId":"20120928223152.GA7906@sigill.intra.peff.net","threadId":"31672","inReplyTo":"m24nmh4x1t.fsf@igel.home","subject":"Re: [PATCH] gitk: refresh the index before running diff-files","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-09-28T22:31:52Z","receivedAt":"2012-09-28T22:31:52Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Sep 29, 2012 at 12:11:58AM +0200, Andreas Schwab wrote:\n\n> Jeff King writes:\n> \n> > +proc refresh_index {} {\n> > + global need_index_refresh\n> > + if { $need_index_refresh } {\n> > +\texec sh -c \"git update-index --refresh >/dev/null 2>&1 || true\"\n> \n> I think the usual idiom for ignoring errors is to use catch around exec,\n> avoiding the extra shell wrapper:\n> \n> catch { exec git update-index --refresh }\n\nThanks. I don't speak tcl at all, but your version makes much more\nsense.\n\n-Peff\n"},{"id":"200141","messageId":"7vipaxkayf.fsf@alter.siamese.dyndns.org","threadId":"31672","inReplyTo":"20120928223152.GA7906@sigill.intra.peff.net","subject":"Re: [PATCH] gitk: refresh the index before running diff-files","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-09-28T23:02:32Z","receivedAt":"2012-09-28T23:02:32Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Sat, Sep 29, 2012 at 12:11:58AM +0200, Andreas Schwab wrote:\n>\n>> Jeff King writes:\n>> \n>> > +proc refresh_index {} {\n>> > + global need_index_refresh\n>> > + if { $need_index_refresh } {\n>> > +\texec sh -c \"git update-index --refresh >/dev/null 2>&1 || true\"\n>> \n>> I think the usual idiom for ignoring errors is to use catch around exec,\n>> avoiding the extra shell wrapper:\n>> \n>> catch { exec git update-index --refresh }\n>\n> Thanks. I don't speak tcl at all, but your version makes much more\n> sense.\n\nBut isn't the redirection still needed? Otherwise the \"Needs\nupdate\" messages will go to the terminal, no?\n"},{"id":"200142","messageId":"20120928230410.GA9851@sigill.intra.peff.net","threadId":"31672","inReplyTo":"7vipaxkayf.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] gitk: refresh the index before running diff-files","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-09-28T23:04:10Z","receivedAt":"2012-09-28T23:04:10Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Sep 28, 2012 at 04:02:32PM -0700, Junio C Hamano wrote:\n\n> >> Jeff King writes:\n> >> \n> >> > +proc refresh_index {} {\n> >> > + global need_index_refresh\n> >> > + if { $need_index_refresh } {\n> >> > +\texec sh -c \"git update-index --refresh >/dev/null 2>&1 || true\"\n> >> \n> >> I think the usual idiom for ignoring errors is to use catch around exec,\n> >> avoiding the extra shell wrapper:\n> >> \n> >> catch { exec git update-index --refresh }\n> >\n> > Thanks. I don't speak tcl at all, but your version makes much more\n> > sense.\n> \n> But isn't the redirection still needed? Otherwise the \"Needs\n> update\" messages will go to the terminal, no?\n\nI think the weird tcl-catches-stderr thing kicks in (at least it did for\nme in a simple experiment). But like I said, I am not an expert.\n\n-Peff\n"},{"id":"200143","messageId":"7vehllka71.fsf@alter.siamese.dyndns.org","threadId":"31672","inReplyTo":"20120928230410.GA9851@sigill.intra.peff.net","subject":"Re: [PATCH] gitk: refresh the index before running diff-files","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-09-28T23:18:58Z","receivedAt":"2012-09-28T23:18:58Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> I think the weird tcl-catches-stderr thing kicks in (at least it did for\n> me in a simple experiment). But like I said, I am not an expert.\n\nOK, I'll believe you ;-)\n"},{"id":"200144","messageId":"m2zk493fai.fsf@igel.home","threadId":"31672","inReplyTo":"7vipaxkayf.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] gitk: refresh the index before running diff-files","fromName":"Andreas Schwab","fromEmail":"schwab@linux-m68k.org","sentAt":"2012-09-28T23:20:53Z","receivedAt":"2012-09-28T23:20:53Z","isPatch":true,"sender":{"key":"schwab@linux-m68k.org","avatar":"https://avatars.githubusercontent.com/u/2175493?v=4"},"body":"Junio C Hamano writes:\n\n> Jeff King writes:\n>\n>> On Sat, Sep 29, 2012 at 12:11:58AM +0200, Andreas Schwab wrote:\n>>\n>>> Jeff King writes:\n>>> \n>>> > +proc refresh_index {} {\n>>> > + global need_index_refresh\n>>> > + if { $need_index_refresh } {\n>>> > +\texec sh -c \"git update-index --refresh >/dev/null 2>&1 || true\"\n>>> \n>>> I think the usual idiom for ignoring errors is to use catch around exec,\n>>> avoiding the extra shell wrapper:\n>>> \n>>> catch { exec git update-index --refresh }\n>>\n>> Thanks. I don't speak tcl at all, but your version makes much more\n>> sense.\n>\n> But isn't the redirection still needed? Otherwise the \"Needs\n> update\" messages will go to the terminal, no?\n\nThe exec command captures both stdout and stderr and returns it as its\nvalue, and catch ignores it.\n\nAndreas.\n\n-- \nAndreas Schwab, schwab@linux-m68k.org\nGPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5\n\"And now for something completely different.\"\n"},{"id":"200187","messageId":"20120930000527.GB4852@bloggs.ozlabs.ibm.com","threadId":"31672","inReplyTo":"20120928205054.GA5985@sigill.intra.peff.net","subject":"Re: [PATCH] gitk: refresh the index before running diff-files","fromName":"Paul Mackerras","fromEmail":"paulus@samba.org","sentAt":"2012-09-30T00:05:27Z","receivedAt":"2012-09-30T00:05:27Z","isPatch":true,"sender":{"key":"paulus@samba.org","avatar":"https://avatars.githubusercontent.com/u/1606439?v=4"},"body":"On Fri, Sep 28, 2012 at 04:50:54PM -0400, Jeff King wrote:\n\n> +proc refresh_index {} {\n> + global need_index_refresh\n> + if { $need_index_refresh } {\n> +\texec sh -c \"git update-index --refresh >/dev/null 2>&1 || true\"\n> +\tset need_index_refresh false\n> + }\n> +}\n\nUnfortunately this will wait for the git update-index command to\ncomplete, making the GUI unresponsive while it executes, and that can\ntake minutes on a large repository (e.g. the linux kernel) on a\nmachine with a slow disk and a cold disk cache. We will need to make\nthe git update-index execute asynchronously.\n\nPaul.\n"},{"id":"200188","messageId":"20120930014203.GA10664@sigill.intra.peff.net","threadId":"31672","inReplyTo":"20120930000527.GB4852@bloggs.ozlabs.ibm.com","subject":"Re: [PATCH] gitk: refresh the index before running diff-files","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-09-30T01:42:04Z","receivedAt":"2012-09-30T01:42:04Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Sep 30, 2012 at 10:05:27AM +1000, Paul Mackerras wrote:\n\n> On Fri, Sep 28, 2012 at 04:50:54PM -0400, Jeff King wrote:\n> \n> > +proc refresh_index {} {\n> > + global need_index_refresh\n> > + if { $need_index_refresh } {\n> > +\texec sh -c \"git update-index --refresh >/dev/null 2>&1 || true\"\n> > +\tset need_index_refresh false\n> > + }\n> > +}\n> \n> Unfortunately this will wait for the git update-index command to\n> complete, making the GUI unresponsive while it executes, and that can\n> take minutes on a large repository (e.g. the linux kernel) on a\n> machine with a slow disk and a cold disk cache. We will need to make\n> the git update-index execute asynchronously.\n\nGood point. We're getting out of my very limited tcl cargo-culting\nskills now, so I'll let somebody more clueful do that fix.\n\n-Peff\n"},{"id":"200222","messageId":"20120930203458.GA31365@elie.Belkin","threadId":"31672","inReplyTo":"20120930014203.GA10664@sigill.intra.peff.net","subject":"Re: [PATCH] gitk: refresh the index before running diff-files","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2012-09-30T20:34:58Z","receivedAt":"2012-09-30T20:34:58Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi Jeff,\n\nJeff King wrote:\n> On Sun, Sep 30, 2012 at 10:05:27AM +1000, Paul Mackerras wrote:\n\n>> Unfortunately this will wait for the git update-index command to\n>> complete, making the GUI unresponsive while it executes, and that can\n>> take minutes on a large repository (e.g. the linux kernel) on a\n>> machine with a slow disk and a cold disk cache. We will need to make\n>> the git update-index execute asynchronously.\n>\n> Good point. We're getting out of my very limited tcl cargo-culting\n> skills now, so I'll let somebody more clueful do that fix.\n\nYou might find the following patch and discussion entertaining:\n\n http://thread.gmane.org/gmane.comp.version-control.git/144182\n\nNot my itch, but it was fun to write back then. ;-)\n\nHope that helps,\nJonathan\n"},{"id":"200300","messageId":"20121001223237.GC12496@sigill.intra.peff.net","threadId":"31672","inReplyTo":"20120930203458.GA31365@elie.Belkin","subject":"Re: [PATCH] gitk: refresh the index before running diff-files","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-10-01T22:32:37Z","receivedAt":"2012-10-01T22:32:37Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Sep 30, 2012 at 01:34:58PM -0700, Jonathan Nieder wrote:\n\n> Jeff King wrote:\n> > On Sun, Sep 30, 2012 at 10:05:27AM +1000, Paul Mackerras wrote:\n> \n> >> Unfortunately this will wait for the git update-index command to\n> >> complete, making the GUI unresponsive while it executes, and that can\n> >> take minutes on a large repository (e.g. the linux kernel) on a\n> >> machine with a slow disk and a cold disk cache. We will need to make\n> >> the git update-index execute asynchronously.\n> >\n> > Good point. We're getting out of my very limited tcl cargo-culting\n> > skills now, so I'll let somebody more clueful do that fix.\n> \n> You might find the following patch and discussion entertaining:\n> \n> http://thread.gmane.org/gmane.comp.version-control.git/144182\n> \n> Not my itch, but it was fun to write back then. ;-)\n\nNot really my itch either, which is why I'm trying to dump the tcl work\non somebody else. :) For what it's worth, your patch from that thread\nlooks like a sane approach.\n\nI don't buy the \"gitk should be read-only\" argument from that thread. I\nthink we decided a while back[1] that the stat cache is not really a\nuser-visible modification; you're not updating the index in any\nmeaningful way that impacts the user's workflow, but merely refreshing\nour cache of what is in the filesystem. That may have performance\nimplications (which is why we do not do it in all commands by default),\nbut it really is a cache, and updating it should be no different than\nupdating gitk.cache (i.e., do it if we can, but do not complain if we\nare in a read-only repository).\n\n-Peff\n\n[1] I did not track down the threads, but I consider this resolved by\n all of the discussion that led to \"git diff\" refreshing (and saving)\n the index rather than printing patch-less stat-dirty entries. The\n original argument against refreshing was that the stat-dirtiness was\n somehow interesting to users, but I think experience has shown that\n people are happy to have it happen magically behind the scenes.\n"},{"id":"200302","messageId":"7vsj9xajn1.fsf@alter.siamese.dyndns.org","threadId":"31672","inReplyTo":"20121001223237.GC12496@sigill.intra.peff.net","subject":"Re: [PATCH] gitk: refresh the index before running diff-files","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-10-01T22:54:10Z","receivedAt":"2012-10-01T22:54:10Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> I don't buy the \"gitk should be read-only\" argument from that thread. I\n> think we decided a while back[1] that the stat cache is not really a\n> user-visible modification; you're not updating the index in any\n> meaningful way that impacts the user's workflow, but merely refreshing\n> our cache of what is in the filesystem.\n\nI think it is OK as long as a failure to \"update-index --refresh\"\ndoes not lead to a user-visible error (I think we made sure that the\nthe opportunistic refresh \"git diff\" and \"git status\" does won't\nreport an error, when you are trying to help your co-worker by\nvisiting her repository and running these commands, only to peek).\n"},{"id":"200390","messageId":"CAEkqydxxmG1QsNUGqQnNn9xfXmS3D3qUvJR6OPV2poabKqcVeQ@mail.gmail.com","threadId":"31672","inReplyTo":"7vr4plkhin.fsf@alter.siamese.dyndns.org","subject":"Re: Git diff-file bug?","fromName":"Scott Batchelor","fromEmail":"scott.batchelor@gmail.com","sentAt":"2012-10-03T08:04:55Z","receivedAt":"2012-10-03T08:04:55Z","isPatch":false,"sender":{"key":"scott.batchelor@gmail.com","avatar":null},"body":"Many thanks to all who have responded to my question.\nI have found that something is, indeed, modifying the inodes for all\nthe files in my repository. Our systems administrator executes a\nbackup using \"tar\" with the \"--atime-preserve\" flag. It is this flag\nthat modifies the \"changed time\" in the inode, and causes gitk to show\nthat all my files have changed.\nThanks,\nScott.\n\nOn 28 September 2012 21:40, Junio C Hamano wrote:\n> Scott Batchelor writes:\n>\n>> I'm fairly new to git and am witnessing some strange behavior with git\n>> that I suspect may be a bug. Can anyone set my mind at rest.\n>>\n>> Every so often (I've not quite figured out the exact set of\n>> circumstances yet)\n>\n> Figure that circumstances out. That is the key to the issue.\n> Something in your workflow is futzing with the inode data of the\n> files in your working tree behind your back. It sometimes is a\n> virus scanner.\n>\n> \"git diff-*\" plumbing commands are meant to be used after running\n> \"git update-index --refresh\" once in the program and when the caller\n> of these commands (in your case, gitk) knows that any change in the\n> information returned by lstat(2) on the paths in the working tree\n> files since that call indicate real changes to the files.\n>\n> \"git status\" internally runs an equivalent of \"--refresh\" before it\n> goes to find changes, so after running it, until that something\n> smudges the inode data behind your back, \"gitk\" will not be\n> confused.\n>\n"},{"id":"200406","messageId":"CAM9Z-nmhxHQF5CxL5ivef=DGpL2mC_67J7g+e7UsNW2U6qcU8Q@mail.gmail.com","threadId":"31672","inReplyTo":"CAEkqydxxmG1QsNUGqQnNn9xfXmS3D3qUvJR6OPV2poabKqcVeQ@mail.gmail.com","subject":"Re: Git diff-file bug?","fromName":"Drew Northup","fromEmail":"n1xim.email@gmail.com","sentAt":"2012-10-03T11:58:15Z","receivedAt":"2012-10-03T11:58:15Z","isPatch":false,"sender":{"key":"n1xim.email@gmail.com","avatar":null},"body":"On Wed, Oct 3, 2012 at 4:04 AM, Scott Batchelor\n wrote:\n> Many thanks to all who have responded to my question.\n> I have found that something is, indeed, modifying the inodes for all\n> the files in my repository. Our systems administrator executes a\n> backup using \"tar\" with the \"--atime-preserve\" flag. It is this flag\n> that modifies the \"changed time\" in the inode, and causes gitk to show\n> that all my files have changed.\n> Thanks,\n> Scott.\n\nScott,\nWe do that in our office @work. Perhaps this will help:\n\n\"core.trustctime\nIf false, the ctime differences between the index and the working tree\nare ignored; useful when the inode change time is regularly modified\nby something outside Git (file system crawlers and some backup\nsystems). See git-update-index(1). True by default.\"\n\n(Quoted via http://git-scm.com/docs/git-config )\n\nWhen/if I have problems I set that false.\n\n\n(CC list reconstructed)\n\n> On 28 September 2012 21:40, Junio C Hamano wrote:\n>> Scott Batchelor writes:\n>>\n>>> I'm fairly new to git and am witnessing some strange behavior with git\n>>> that I suspect may be a bug. Can anyone set my mind at rest.\n>>>\n>>> Every so often (I've not quite figured out the exact set of\n>>> circumstances yet)\n>>\n>> Figure that circumstances out. That is the key to the issue.\n>> Something in your workflow is futzing with the inode data of the\n>> files in your working tree behind your back. It sometimes is a\n>> virus scanner.\n>>\n>> \"git diff-*\" plumbing commands are meant to be used after running\n>> \"git update-index --refresh\" once in the program and when the caller\n>> of these commands (in your case, gitk) knows that any change in the\n>> information returned by lstat(2) on the paths in the working tree\n>> files since that call indicate real changes to the files.\n>>\n>> \"git status\" internally runs an equivalent of \"--refresh\" before it\n>> goes to find changes, so after running it, until that something\n>> smudges the inode data behind your back, \"gitk\" will not be\n>> confused.\n\n-- \n-Drew Northup\n--------------------------------------------------------------\n\"As opposed to vegetable or mineral error?\"\n-John Pescatore, SANS NewsBites Vol. 12 Num. 59\n"}]}