A command like git-annex oldkeys $file
that lists the keys used for all
previous versions of the file.
It would allow a workflow like eg:
edit foo
git-annex add foo
git commit -m new\ foo
git-annex oldkeys foo | git-annex move --batch-keys --to bar
Or this, to send someone the current version of a file, and also all old versions:
git-annex copy foo --to baz
git-annex oldkeys foo | git-annex copy --to baz
Or like this:
git-annex oldkeys foo | git-annex get --batch-keys
# proceed to diff between old versions of the file
# (although git-annex-diffdriver --get is another way to do this)
Or this to make every old version visible as files to flip through in a slideshow:
n=0
for k in $(git-annex oldkeys my.gif); do
$n=$(expr $n + 1)
ln -s $(git-annex examinkey $k --format='${objectpath}') my.$n.gif
done
Is oldkeys the best name for this? git-annex log
is already taken.
Since this would be implemented on top of git log --raw
, it would
be possible to support multiple files at once, or whole directories.
If an old key is the same as the current key, should it list the old key or not? If it did, then the move example above would move the current version of the file away. And there are tricky cases involving renames and reverts. So it seems that it ought to avoid ever listing a key currently used by the file(s) it is run on as an old key.
unusedkeys
would be consistently named withgit annex unused
. Would it make sense to teachgit annex unused
that? It could be taught to accept paths as arguments (it doesn't currently, right?) and then only operate on those to find old versions. Then no new command is necessary and people already knowunused
. The workflow would be:git annex unused
accept the common matching options. Thengit annex unused --include=myfile.txt
can be used for the same effect.This is certainly adjacent to unused, but it's not quite the same.
I think users will generally want this to list keys even if they are still used by some other files in the tree besides the files that they are querying. (There may be cases where that is not desirable of course, but at least 3 of the 4 examples I came up with seem desirable to operate that way.)
And a key listed by this command might be used by other branches, so unused would not list it.