blob: 72ff677fc4faca04d3335c4eedaf59f39c293829 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
|
[[!comment format=mdwn
username="joey"
subject="""comment 1"""
date="2017-12-08T18:58:18Z"
content="""
This is due to lookupkey not passing the filename through git ls-files like
most (all?) other commands do.
Using git ls-files would lead to other behavior changes though. It recurses into
directories. I don't think it makes sense for lookupkey to recurse into
directories, because its output format does not include the filename, so
listing a bunch of keys for annexed files is not clear. git annex find
can already recurse and can use a format with the key and the filename
that's suited for directory recursion. git annex lookupkey, as plumbing,
is supposed to be simpler than that.
I suppose lookupkey could normalize absolute file paths, checking if they
point into the git repository. I don't think that git-annex contains
such normalization code, and it might be a lot more complicated than it at
first seems -- git has a lot of wrinkles with submodules, symlinks, etc etc.
git does not seem to have a suitable command to do it.
So seems the best way is to use git ls-files and detect when it's recursing,
and exit nonzero then.
"""]]
|
