$ 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.
Changing file extension is arguably not a very common use case. But changing extension case is more common, especially when copying files from FAT filesystems through different ways (Card reader, plugging device directly), and causes troubles.
Concrete case
A set of files were imported with extension NEF and JPG, by mistake (forgot to rename them first), using default (or is it?) backend SHA256E.
When using
git annex reinject --knownto cleanup another copy, files were not detected as known.This will happen again and feels not very good.
Workaround
Thanks to CandyAngel I know I can rename then use
git annex migrate --forceandreinjectagain.Better solution
A SHA256e backend (that squashes extensions to lowercase) would not have this problem.
Additional information
Why not switch to plain SHA256 backend? I'm a little paranoid (which makes me a good fit for using git-annex overall).
One of the reason I use git-annex is that its storage format is actually simple, and files can be accessed even on a computer that can read the plain filesystem, without git or git-annex required. But in the lifetime of a filesystem, many bad things can happen and details of storage format may make a difference in case of major recovery (or even sanity check) scenario. Hashes without extension feel somehow uncomfortable. Lowercase extension backends feel much better.
Didn't catch this from the docs above:
"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."
Hey Joey,
Just wondering how we rename/move files around into different directories within a repository without breaking the symbolic links. If we move to a different directory and the depth is different than where the files were originally in the repo then the symbolic link is broken.
Thanks
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
.giffile 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?