On Mon, Apr 08, 2013 at 12:53:52PM -0400, Joey Hess wrote:
> mv .git/annex/bad . 
> git annex add bad
> rm -rf bad

Can you please explain how that should work? When I run that, it looks
like git-annex just thinks I want to add new files, and git status
reports this:

# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       new file:
        
bad/SHA256E-s11928--5f9e55f7d4eb7842a759ef247b94162eef66b38db8a1fd8f784d38f7c67a65fb.csv.xls
#       new file:
        
bad/SHA256E-s131630--490dfc84fa04b89ca45b79f19c2aa5c6b4813b028a6dbd4f877a3cce218f81ad.orig.jpg
#       new file:
        
bad/SHA256E-s1498112--4a50e245a9d1a0fb30fea2a34fa43843b5428b209a7656d0ca61826ca0769552.0.ppt

(...)

# Changes not staged for commit:
#   (use "git add/rm <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working
#   directory)
#
#       deleted:
        
bad/SHA256E-s11928--5f9e55f7d4eb7842a759ef247b94162eef66b38db8a1fd8f784d38f7c67a65fb.csv.xls
#       deleted:
        
bad/SHA256E-s131630--490dfc84fa04b89ca45b79f19c2aa5c6b4813b028a6dbd4f877a3cce218f81ad.orig.jpg
#       deleted:
        
bad/SHA256E-s1498112--4a50e245a9d1a0fb30fea2a34fa43843b5428b209a7656d0ca61826ca0769552.0.ppt

And if I try to commit the change, no magic happens, and the files
does not appear under the original place under .git/annex/objects:

# On branch master
nothing to commit (working directory clean)

I still have the original repository where I can easily copy the files
from, but maybe it would be useful to have the working procedure
documented (at least in this bug report) for those who have this
problem with their only copy. Of course it's quite trivial to write
a script that finds the dangling symlinks and moves the bad files
to the corresponding place; with a small number of files it is even
feasible to do it manually.

Furthermore, I think that many (most?) users assume that "git annex
fsck" is a non-destructive operation by default--as, I believe, "git
fsck" is (or traditional file system fsck without -y). At least I was
under the impression that it should not modify my repository in any
way, and just report the possible issues. Perhaps you might want to
consider changing it that way, or adding a warning to the
documentation.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to