what is the work flow to get a file that is in git-annex out of there and into git? (current situation: git-annex add
ed a bunch of pictures, later found make files in there which i'd rather have in git for proper source code control)
the most intuitive thing to do is git unannex
, which at first seemed to do the right thing, but when committing there came the hook and everything was back to where it was before.
i could disable the hook as a workaround, but that doesn't smell like a good work flow.
the man page does warn that unannex
is only supposed to be used against unintentional git annex add
s (probably meaning that it should be used before something is committed), but the alternatives it suggests (git rm
and git annex drop
) don't to what i want to do.
am i missing something or is there really no work flow for this? --chrysn
Git-annex's commit hook does not prevent unannex being used. The file you unannex will not be checked into git anymore and will be a regular file again, not a git-annex symlink.
For example, here's a transcript:
And following on to my transcript, you can then add the file to git in the regular git way, and it works fine:
Sorry for all the followups, but I see now that if you unannex, then add the file to git normally, and commit, the hook does misbehave.
This seems to be a bug. git-annex's hook thinks that you have used git annex unlock (or "git annex edit") on the file and are now committing a changed version, and the right thing to do there is to add the new content to the annex and update the symlink accordingly. I'll track this bug over at unannex vs unlock hook confusion.
So, committing after unannex, and before checking the file into git in the usual way, is a workaround. But only if you do a "git commit" to commit staged changes.
Anyway, this confusing point is fixed in git now!
This is still occurring for me. If I unannex, then commit the deletion, drop the key, and add back the file now with
git add
, annex usurps the commit and commits only a pointer. Then,git annex find --unlocked
shows the file as an unlocked annexed file.git show HASH
shows the pointer, not the file contents, thus my worry that the contents are lost in the git repo. What's worse,git hash-object
gives the same hash as shown ingit log --raw
so by plain inspection of the log it seems like the content is properly logged in the git repo but it's not!It appears the bug you mentioned has been closed/deleted (instead of moved to done). I am going to reopen it and put in my details.