Re: Git diff-file bug?
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. 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 confused. -- 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
Re: Git diff-file bug?
On Wed, Oct 3, 2012 at 4:04 AM, Scott Batchelor scott.batche...@gmail.com wrote: 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) 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 confused. -- -Drew Northup -- 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
Re: Git diff-file bug?
On Fri, Sep 28, 2012 at 07:55:10PM +0100, Scott Batchelor wrote: 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. It's not a bug. Every so often (I've not quite figured out the exact set of circumstances yet) git diff-files shows that every file in my repo is modified, when I expect none to be. Diff-files only looks at the cached sha1 in the index. It will not re-read the file to update its index entry if its stat information appears out of date. So what is happening is that another program[1] is updating the timestamp or other information about each file, but not the content. Diff-files does not re-read the content to find out there is in fact no change. If you are using plumbing like diff-files, you are expected to run git update-index --refresh yourself first. The reasoning is that for performance reasons, a script that issues many git commands would only want to pay the price to refresh the index once, at the beginning of the script. If you use the git diff porcelain, it will automatically refresh the index for you. If I type git status (which shows what I expect - no files modified) and then git diff-files again, git now shows that no files have been modified (which is what I expect). It's like git status is resetting something that git diff-files uses. Exactly. git status automatically refreshes the index, and the result is saved. I'm trying to figure out what the problem with git diff-files is because gitk uses it under the hood, and I think that gitk is reporting erroneous changes (which are also reset by performing a git status in the repo) in the patch files list. gitk should probably be calling update-index --refresh on startup. If it already is, then it may be that whatever is updating the files is doing it while gitk is running. -Peff [1] Usually stat updates are caused by another program. But we have had cases where unusual filesystems yielded inconsistent results from stat(). -- 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
