{"thread":{"id":"50166","subject":"gitk shows local uncommit changes after touch file + reload","startedAt":"2019-01-06T22:52:09Z","lastAt":"2019-01-08T06:41:05Z","messageCount":3,"participants":["Jacob Kroon","Philip Oakley"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"366227","messageId":"CAPbeDCm5hjq06fbs=SUPR1rm3bD3GJvifZovP1d-Xd=01JfpYQ@mail.gmail.com","threadId":"50166","inReplyTo":null,"subject":"gitk shows local uncommit changes after touch file + reload","fromName":"Jacob Kroon","fromEmail":"jacob.kroon@gmail.com","sentAt":"2019-01-06T22:51:55Z","receivedAt":"2019-01-06T22:52:09Z","isPatch":false,"sender":{"key":"jacob.kroon@gmail.com","avatar":null},"body":"Hi,\n\nNot sure if this has already been reported, but I observe this odd\nbehaviour in gitk from master:\n\ngit status\ngitk # everything looks good\ntouch \ngitk # gitk shows \"local uncomitted changes\" on the file I touched\ngit status\ngitk # gitk is back to normal again, showing no local uncommitted changes\n\nThe issue has been discussed on stackoverflow here:\nhttps://stackoverflow.com/questions/49990403/after-tar-untar-of-git-repo-gitk-shows-local-uncommitted-changes-not-checked\n\nAny chance gitk could be changed to so that it doesn't display the\n\"local uncommitted changes\" blob in this case ?\n\nRegards Jacob\n"},{"id":"366271","messageId":"2666a093-f9a5-782e-40b3-0cfbce8fe2a3@iee.org","threadId":"50166","inReplyTo":"CAPbeDCm5hjq06fbs=SUPR1rm3bD3GJvifZovP1d-Xd=01JfpYQ@mail.gmail.com","subject":"Re: gitk shows local uncommit changes after touch file + reload","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2019-01-07T17:41:02Z","receivedAt":"2019-01-07T17:41:05Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"On 06/01/2019 22:51, Jacob Kroon wrote:\n> Hi,\n>\n> Not sure if this has already been reported, but I observe this odd\n> behaviour in gitk from master:\n>\n> git status\n> gitk # everything looks good\n> touch \n> gitk # gitk shows \"local uncomitted changes\" on the file I touched\n> git status\n> gitk # gitk is back to normal again, showing no local uncommitted changes\n>\n> The issue has been discussed on stackoverflow here:\n> https://stackoverflow.com/questions/49990403/after-tar-untar-of-git-repo-gitk-shows-local-uncommitted-changes-not-checked\n>\n> Any chance gitk could be changed to so that it doesn't display the\n> \"local uncommitted changes\" blob in this case ?\n>\n> Regards Jacob\n\nI believe this is doing the right thing (TM) at the level of \ninvestigation that gitk uses to determine the status of the files. In \nparticular, Git uses the modified time stamp as a surrogate indication \nfor detecting that the user has probably edited the file (it's been \nmodified at time hhmmss, right?).\n\nNow as I understand it, the full (without limiting options) git status \ncommand does go and check the content of anything that's potentially \nchanged (but it can be costly), and at that point the status command \nsimply updates its 'Index' record with the new mtime after noticing that \nnothing had really changed. Meanwhile, gitk, being a continuously \nrunning GUI avoids the overhead of the git status (though you can force \nit) and does report the mtime change as being a potential file modification.\n\nThere is a separate discussion on the git users forum regarding the \ncompatibility with other tools that has a similar root cause in the use \nand abuse of mtime as a canary for modification, given that the Git repo \nstorage does not record any file times, so will get a (moderately) \narbitrary mtime & ctime when checked out.\n\n-- \n\nPhilip\n\n"},{"id":"366317","messageId":"0c4b21c8-996b-3017-a1f9-894ac5b27232@gmail.com","threadId":"50166","inReplyTo":"2666a093-f9a5-782e-40b3-0cfbce8fe2a3@iee.org","subject":"Re: gitk shows local uncommit changes after touch file + reload","fromName":"Jacob Kroon","fromEmail":"jacob.kroon@gmail.com","sentAt":"2019-01-08T06:41:00Z","receivedAt":"2019-01-08T06:41:05Z","isPatch":false,"sender":{"key":"jacob.kroon@gmail.com","avatar":null},"body":"On 1/7/19 6:41 PM, Philip Oakley wrote:\n> On 06/01/2019 22:51, Jacob Kroon wrote:\n>> Hi,\n>>\n>> Not sure if this has already been reported, but I observe this odd\n>> behaviour in gitk from master:\n>>\n>> git status\n>> gitk # everything looks good\n>> touch \n>> gitk # gitk shows \"local uncomitted changes\" on the file I touched\n>> git status\n>> gitk # gitk is back to normal again, showing no local uncommitted changes\n>>\n>> The issue has been discussed on stackoverflow here:\n>> https://stackoverflow.com/questions/49990403/after-tar-untar-of-git-repo-gitk-shows-local-uncommitted-changes-not-checked \n>>\n>>\n>> Any chance gitk could be changed to so that it doesn't display the\n>> \"local uncommitted changes\" blob in this case ?\n>>\n>> Regards Jacob\n> \n> I believe this is doing the right thing (TM) at the level of \n> investigation that gitk uses to determine the status of the files. In \n> particular, Git uses the modified time stamp as a surrogate indication \n> for detecting that the user has probably edited the file (it's been \n> modified at time hhmmss, right?).\n> \n> Now as I understand it, the full (without limiting options) git status \n> command does go and check the content of anything that's potentially \n> changed (but it can be costly), and at that point the status command \n> simply updates its 'Index' record with the new mtime after noticing that \n> nothing had really changed. Meanwhile, gitk, being a continuously \n> running GUI avoids the overhead of the git status (though you can force \n> it) and does report the mtime change as being a potential file \n> modification.\n\nAlthough gitk it is a continuously running application, I don't expect \nit is continuously monitoring the files. If I explicitly tell gitk to \n\"reload\" I'd be perfectly fine with it taking some more time to discard \nany false positives in the same way as \"git status\".\n\nWhat do you mean by \"you can force it\", is there some option in gitk I \ncan set which forces it to do the equivalent of \"git status\" on reload ?\n\nThanks,\nJacob\n\n> There is a separate discussion on the git users forum regarding the \n> compatibility with other tools that has a similar root cause in the use \n> and abuse of mtime as a canary for modification, given that the Git repo \n> storage does not record any file times, so will get a (moderately) \n> arbitrary mtime & ctime when checked out.\n> \n"}]}