diff options
author | 2015-12-19 13:36:40 -0400 | |
---|---|---|
committer | 2015-12-19 13:36:40 -0400 | |
commit | fb4be5f9b2d5794cb45f8c335ae8de5700947241 (patch) | |
tree | 86c0c5caff039a32404df29260783ba4c4119258 /doc | |
parent | ff32fb971708f5351c8c23a8fd1e0d59f48fe894 (diff) |
status: On crippled filesystems, was displaying M for all annexed files that were present. Probably caused by a change to what git status displays in this situation. Fixed by treating files git thinks are modified the same as typechanged files.
Diffstat (limited to 'doc')
-rw-r--r-- | doc/forum/Git_annex_status_always_showing_annexed_files_as_modified/comment_6_54155343eef8c6f95574dffb3910fc61._comment | 46 |
1 files changed, 46 insertions, 0 deletions
diff --git a/doc/forum/Git_annex_status_always_showing_annexed_files_as_modified/comment_6_54155343eef8c6f95574dffb3910fc61._comment b/doc/forum/Git_annex_status_always_showing_annexed_files_as_modified/comment_6_54155343eef8c6f95574dffb3910fc61._comment new file mode 100644 index 000000000..6f179bcc1 --- /dev/null +++ b/doc/forum/Git_annex_status_always_showing_annexed_files_as_modified/comment_6_54155343eef8c6f95574dffb3910fc61._comment @@ -0,0 +1,46 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 6""" + date="2015-12-19T16:30:55Z" + content=""" +Sorry I haven't had a chance to think about this problem any more. +The v6 repository format I've been working on should eliminate class problem +anyway. It will let git itself be able to tell if annexed files are modified +or not. + +But there is something you can try to debug what's going on. + +0. Run the git bash shell and cd to your repository's directory. +1. `cat .git/annex/sentinal.cache` and paste its content. +2. `stat .git/annex/sentinal --terse` and paste the output of that. +2. Pick one of the files wrongly showing as modified. Run `stat $file --terse` + and paste the output of that. +3. And then this command should output the inode cache for the file. + Be sure to replace $file with the name of the file: + `cat $(git annex find $file --format='.git/annex/objects/${hashdirlower}${key}/${key}.cache`) + +But hmm, as I was running windows to get these instructions, I seem to have +reproduced the problem myself! In my case: + +* The sentinal.cache contained data matching the stat of the sentinal file. +* The annexed file's mtime and size (and even inode) matched the cached + values. +* `git annex status` showed the file as modifed; `git annex sync` found + nothing to commit and didn't change that. + +Some more debugging and.. It seems this is not a horrible windows-specific +time zone problem. Thank goodness. Instead, what's going on is that `git -c +core.bare=false status` does not show these files as typechanged, but as +modified instead. Since `git annex status` only has special case handling +for typechanged files, it just passes the M through and displays it. + +So, this is only a display problem, and thus nothing to worry about really. +Ie, the rest of git-annex's behavior should not be impacted at all. + +It's not windows specific.. Same happens on FAT on Linux. I think git's +behavior probably changed since an earlier version; I'm pretty sure its +status showed typechanged before. Anyway, I've fixed the status display, +on these systems it will now treat files git says are modified the same +as typechanged, and so will use git-annex's inode cache info to diplay +an accurate status for them. +"""]] |