# cd ~/annex
# git mv big_file my_cool_big_file
# mkdir iso
# git mv debian.iso iso/
# git commit -m moved
You can use any normal git operations to move files around, or even make copies or delete them.
Notice that, since annexed files are represented by symlinks, the symlink will break when the file is moved into a subdirectory. But, git-annex will fix this up for you when you commit -- it has a pre-commit hook that watches for and corrects broken symlinks.
(Note that if a repository is in direct mode, you can't run normal git
commands in it. Instead, just move the files using non-git commands, and
git annex add
and git annex sync
.)
This is basically the same as thinking that git should change the SHA1 used to refer to a file in the repository just because it was renamed. That does not normally make sense.
Including the original extension in the git-annex key is done to avoid confusing some poorly-behaved programs that expect to follow the symlink and find a file with an extension. It's best to ignore the extension part of the key, or if you like, you can change the backend from SHA256E to SHA256, and then new keys won't include that extension.
migrate takes the --force option (introduced 5.20150327), allowing you to migrate files to the backend they are already using, but using the new extension. It was actually added for this use case!
This may still incur a hash of the file though as, I believe, migrate will check the file at the old key is valid. You will also end up with 2 versions of the file in .git/annex/objects though (you can clean it up with unused).
I tried to rename a
.gif
file to.jpg
:I would expect that the last extension printed is .jpg, rather than .gif. How do I make git-annex fix that, preferably without calling
git annex fsck
, which is very slow, because it rehashes the file?