The same way that git-annex-import has a --duplicate option,
there should be a way to reinject content without dropping the
original file.
My use case is that I had imported content in the wrong git-annex repository, by mistake. Unaware of my mistake, I moved the files (now symlinks) to the proper git-annex repo, where I added them and where they (obviously) were broken. So I tried to fix that with reinject:
$ git annex reinject --known ~/mp3/.git/annex/objects/xJ/K5/SHA256E-s16309242--41eb375ac760bf8542bae1ec2bcfce9269f78302820bcc88904e76bab473181c.flac/SHA256E-s16309242--41eb375ac760bf8542bae1ec2bcfce9269f78302820bcc88904e76bab473181c.flac
reinject /home/anarcat/mp3/.git/annex/objects/xJ/K5/SHA256E-s16309242--41eb375ac760bf8542bae1ec2bcfce9269f78302820bcc88904e76bab473181c.flac/SHA256E-s16309242--41eb375ac760bf8542bae1ec2bcfce9269f78302820bcc88904e76bab473181c.flac
git-annex: /home/anarcat/mp3/.git/annex/objects/xJ/K5/SHA256E-s16309242--41eb375ac760bf8542bae1ec2bcfce9269f78302820bcc88904e76bab473181c.flac/SHA256E-s16309242--41eb375ac760bf8542bae1ec2bcfce9269f78302820bcc88904e76bab473181c.flac: rename: permission denied (Permission denied)
failed
(recording state in git...)
git-annex: reinject: 1 failed
It almost worked but failed because it cannot rename the git-annex file on the other side. But worse, copying the file by hand does not work either:
$ LANG=C cp ~/mp3/.git/annex/objects/xJ/K5/SHA256E-s16309242--41eb375ac760bf8542bae1ec2bcfce9269f78302820bcc88904e76bab473181c.flac/SHA256E-s16309242--41eb375ac760bf8542bae1ec2bcfce9269f78302820bcc88904e76bab473181c.flac ../../../.git/annex/objects/xJ/K5/SHA256E-s16309242--41eb375ac760bf8542bae1ec2bcfce9269f78302820bcc88904e76bab473181c.flac/SHA256E-s16309242--41eb375ac760bf8542bae1ec2bcfce9269f78302820bcc88904e76bab473181c.flac
cp: cannot create regular file '../../../.git/annex/objects/xJ/K5/SHA256E-s16309242--41eb375ac760bf8542bae1ec2bcfce9269f78302820bcc88904e76bab473181c.flac/SHA256E-s16309242--41eb375ac760bf8542bae1ec2bcfce9269f78302820bcc88904e76bab473181c.flac': Permission denied
... obviously because the directory already exists and is not
writable. The workaround is to create those directories if missing
(mkdir -p) or change the mode if present (chmod u+w), then run
git-annex-fsck which will fix those modes.
Other than making reinject work against a fellow git-annex repository, I think this would be useful to avoid deleting files which might surprise users... I suggest using a logic similar to git-annex-import for consistency reasons.
Thanks! -- anarcat
The first word of the git-annex-reinject man page is "moves", so I find it hard to believe users would be surprised that it does that. (Also, "inject" suggests movement.)
I can't see this being anything but an option added to reinject, because changing behavior to copying when it's been move would be surprising, and could result in a lot of unwanted disk space being used or other problems with some workflow that involves reinject.
I am doubtful that such an option is worth it given the way git-annex reinject is usually used.
And if I were in your situation, which I have been, I'd just delete the symlinks I moved by accident, check them back out in the other repository, and then unannex the files and move them. Much easier than running reinject with long paths into the other repository.