Re: Git diff-file bug?
- From
- Drew Northup <n1xim.email@gmail.com>
- Date
- Oct 3, 2012, 11:58 UTC
- Message-ID
- <CAM9Z-nmhxHQF5CxL5ivef=DGpL2mC_67J7g+e7UsNW2U6qcU8Q@mail.gmail.com>
- In-Reply-To
- <CAEkqydxxmG1QsNUGqQnNn9xfXmS3D3qUvJR6OPV2poabKqcVeQ@mail.gmail.com>
On Wed, Oct 3, 2012 at 4:04 AM, Scott Batchelor <scott.batchelor@gmail.com> wrote:
Show 8 quoted lines
> 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. > Thanks, > Scott.
Scott, We do that in our office @work. Perhaps this will help:
"core.trustctime 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)
Show 24 quoted lines
> On 28 September 2012 21:40, Junio C Hamano <gitster@pobox.com> wrote: >> Scott Batchelor <scott.batchelor@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 >> confused.
-- -Drew Northup -------------------------------------------------------------- "As opposed to vegetable or mineral error?" -John Pescatore, SANS NewsBites Vol. 12 Num. 59