Re: gitk shows local uncommit changes after touch file + reload
- Date: Tue, 8 Jan 2019 07:41:00 +0100
- From: Jacob Kroon <jacob.kroon@xxxxxxxxx>
- Subject: Re: gitk shows local uncommit changes after touch file + reload
On 1/7/19 6:41 PM, Philip Oakley wrote:
On 06/01/2019 22:51, Jacob Kroon wrote:
Not sure if this has already been reported, but I observe this odd
behaviour in gitk from master:
gitk # everything looks good
gitk # gitk shows "local uncomitted changes" on the file I touched
gitk # gitk is back to normal again, showing no local uncommitted changes
The issue has been discussed on stackoverflow here:
Any chance gitk could be changed to so that it doesn't display the
"local uncommitted changes" blob in this case ?
I believe this is doing the right thing (TM) at the level of
investigation that gitk uses to determine the status of the files. In
particular, Git uses the modified time stamp as a surrogate indication
for detecting that the user has probably edited the file (it's been
modified at time hhmmss, right?).
Now as I understand it, the full (without limiting options) git status
command does go and check the content of anything that's potentially
changed (but it can be costly), and at that point the status command
simply updates its 'Index' record with the new mtime after noticing that
nothing had really changed. Meanwhile, gitk, being a continuously
running GUI avoids the overhead of the git status (though you can force
it) and does report the mtime change as being a potential file
Although gitk it is a continuously running application, I don't expect
it is continuously monitoring the files. If I explicitly tell gitk to
"reload" I'd be perfectly fine with it taking some more time to discard
any false positives in the same way as "git status".
What do you mean by "you can force it", is there some option in gitk I
can set which forces it to do the equivalent of "git status" on reload ?
There is a separate discussion on the git users forum regarding the
compatibility with other tools that has a similar root cause in the use
and abuse of mtime as a canary for modification, given that the Git repo
storage does not record any file times, so will get a (moderately)
arbitrary mtime & ctime when checked out.