blob: acd661feb08172261adfc8d009dab4d11e3ebe5b (
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
26
|
[[!comment format=mdwn
username="joey"
subject="""comment 2"""
date="2015-03-26T15:28:45Z"
content="""
Well, you've found an edge case here.
It behaves as documented as long as the file being imported is located in some
repository know to git-annex. The file content does not have to be present in
the local repository for it to behave as documented.
In your case, the file being imported has a symlink in the git repo, but
git-annex knows about 0 annexed copies of the file, so it's treated as
if it's a new file and not a duplicate.
Since import is working at the key level, there's not a good way to look up
that there are some symlinks in the git repo even though the content is
gone. And even if there was, I think I'd be uncomfortable with it deleting
the file as "duplicate" when its content is not available in any known
repository. The only behavior improvement might be to import the content
but not make a redundant symlink in this case.
I think it's best to change the documentation. I've added a new
paragraph that more exactly and clearly explains what duplicate files
are for the purposes of importing.
"""]]
|
