On Wed, Oct 3, 2012 at 4:04 AM, Scott Batchelor
> Many thanks to all who have responded to my question.
> I have found that something is, indeed, modifying the inodes for all
> the files in my repository. Our systems administrator executes a
> backup using "tar" with the "--atime-preserve" flag. It is this flag
> that modifies the "changed time" in the inode, and causes gitk to show
> that all my files have changed.
We do that in our office @work. Perhaps this will help:
If false, the ctime differences between the index and the working tree
are ignored; useful when the inode change time is regularly modified
by something outside Git (file system crawlers and some backup
systems). See git-update-index(1). True by default."
(Quoted via http://git-scm.com/docs/git-config )
When/if I have problems I set that false.
(CC list reconstructed)
> On 28 September 2012 21:40, Junio C Hamano <gits...@pobox.com> wrote:
>> Scott Batchelor <scott.batche...@gmail.com> writes:
>>> I'm fairly new to git and am witnessing some strange behavior with git
>>> that I suspect may be a bug. Can anyone set my mind at rest.
>>> Every so often (I've not quite figured out the exact set of
>>> circumstances yet)
>> Figure that circumstances out. That is the key to the issue.
>> Something in your workflow is futzing with the inode data of the
>> files in your working tree behind your back. It sometimes is a
>> virus scanner.
>> "git diff-*" plumbing commands are meant to be used after running
>> "git update-index --refresh" once in the program and when the caller
>> of these commands (in your case, gitk) knows that any change in the
>> information returned by lstat(2) on the paths in the working tree
>> files since that call indicate real changes to the files.
>> "git status" internally runs an equivalent of "--refresh" before it
>> goes to find changes, so after running it, until that something
>> smudges the inode data behind your back, "gitk" will not be
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html