Please describe the problem.
I understand that git annex unannex is essentially there for undoing an accidental git annex add. Unfortunately it doesn't do that.
If I have uncommitted changes, which is the case after a git annex add, it tells me:
git-annex: Cannot proceed with uncommitted changes staged in the index. Recommend you: git commit
CallStack (from HasCallStack):
error, called at ./Command/Unannex.hs:48:19 in main:Command.Unannex
But I would expect it to git reset the file and then replace the symlink by the actual file content.
What steps will reproduce the problem?
> git init
Initialized empty Git repository in /somewhere/.git
> git annex init
init ok
(recording state in git...)
> touch foo
> git annex add foo
add foo ok
(recording state in git...)
> git annex unannex foo
git-annex: Cannot proceed with uncommitted changes staged in the index. Recommend you: git commit
CallStack (from HasCallStack):
error, called at ./Command/Unannex.hs:48:19 in main:Command.Unannex
What version of git-annex are you using? On what operating system?
git-annex version: 6.20160527-gf21a425
Installed from the Arch Linux repository.
Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
Sure, I'm using it for photos, music and videos
In v5 mode, there is a complex interaction between unannex and the pre-commit hook. An unannexed file looks quite a lot like an unlocked file, so the pre-commit hook is prone to want to lock it, and so add it back to the annex as an annexed file.
To avoid that problem, unannex needs to commit the unannexing of the files.
However, if you have other staged changes, they'll also be included in that commit. Which would be a bug if it were allowed to happen. This is why it checks for a clean index first.
It would be possible to improve the behavior by explicitly committing only the files that got unannexed, rather than all staged changes. Why didn't I do that?
Well,
git commit $filestages any changes to the file's content before committing. When the file has been unannexed, this stages the entire large file content into git, and adds it back. Not the desired behavior!Git in fact has no interface to make it commit only staged changes to only specific files. I can't get there from here. It would certianly be nice if git got the ability to do that, if someone wants a project to improve git.
It's very nice that v6 mode avoids this problem entirely!
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
unannexto do. Looks like I expected exactly the same behavior.IMHO current behavior of
git annex unannexdoes not match what people expect of "undo accidental add command".What current
git-annex unannexactually doesIf 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:Notice that:
git-annexretains historygit-annex dropunused.Thank you for your attention.