Where we are

@joey thank you for these explanations, more detailed than when I reported the same problem 8 months ago commenting https://git-annex.branchable.com/git-annex-unannex/ (@tom.prince had already written this page but I did not find it).

Yet all this happens in a git world, where private history can be rewritten, so there must be a simpler way.

What people expect from "undo accidental add command"

@tom.prince thanks for explaining what you expected unannex to do. Looks like I expected exactly the same behavior.

IMHO current behavior of git annex unannex does not match what people expect of "undo accidental add command".

What current git-annex unannex actually does

If behavior does not match words, perhaps behavior is interesting but should be matched with different words?

Looking at what git-annex unannex, here are the words that came to mind:

git-annex unannex - turn a path which points to annexed content into a plain file that is store in regular git.

Notice that:

• git-annex retains history
• other paths may still refer to the same content, so the annex may still contain a copy of the same data. Else it becomes unused content subject to git-annex dropunused.

Thank you for your attention.

I couldn't get this to run and had a lot of performance issues with rclone on Google Drive, so I adapted the rclone wrapper to gdrive. It's running fine so far, so I thought I share it:

https://github.com/Lykos153/git-annex-remote-gdrive

As far as I can tell, from looking at the code, the pre-commit hook only looks at files in the index. Thus, if unannexing an uncommited file removed it from the index, the pre-commit will do the right thing. This would be nice to have, at least for the case where the files have never been committed.

My solution is very roundabout but preserves a lot of information, but did involve buying another drive (and exclusively using v5 indirect mode!).

I create a new repository (on the new drive) which I import all the contents of the "keyfiles" (contents of .git/annex/objects). Then I create another repository with the filelinks (symlinks pointing to .git/annex/objects). After adding the keyfiles remote to this, this lets me see which content is present and valid, which got corrupted, is missing etc.

Then I can move the valid content from this recovery annex into a proper annex and try and repair/find the corrupted/missing.

1) Check out the source repository group, which will drop files once enough numcopies are available elsewhere 2) This is pretty much why git-annex exists 3) Set numcopies to 2 and use 'git annex fsck' to find out when there aren't enough copies 4) You can use 'import' or 'reinject --known' to clean up known content outside of git-annex 5) git-annex will run on 'crippled' filesystems like FAT32. Would recommend avoiding this if possible though 6) This is presumed

Sorry for brevity, but this should give some direction/keywords.

More specific information is in https://git-annex.branchable.com/forum/Fix_duplicate_UUID/

(Another user here.)

I can't take you by the hand but all this seems like regular use of git-annex.

I was overwhelmed at the beginning, followed http://git-annex.branchable.com/walkthrough , visited a number of pages. I finally had something that worked.

In some cases you might consider, instead of moving files then using git annex add, using https://git-annex.branchable.com/git-annex-import/ with or without some of the options.

If you have specific problems, ask a more specific question.

Happy journey!

Symbolic links point to ......./.git/annex/objects/.....

So, you can have them work by making your .git/annex/objects a link to the main repo's .git/annex/objects.

cd $mylightweightclone/.git/annex
mv objects objects.empty # move away but keep, just in case
ln -s $centralrepository/.git/annex/objects

If the lightweight clone only performs read operations, I would expect things to work fine.

I don't know if it can be dangerous to the health of your central repository besides that, so be careful.

Thanks for sharing. I stumbled upon a similar problem and (IIRC) ended up doing at least one new clone. I don't know if your solution is fully clean but it seems to have lower cost.

Hello.

Any progress on this? (With regular git annex I now have a big repository with some corruption and git annex repair causes oom-kill.)