blob: 9b9bb6342eacf79c33aa8c97f054b9ef1ca2c97e (
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
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
|
What steps will reproduce the problem?
+ ```~/``` is tracked by git and git annex
+ ```~/text/books/foo``` is annexed
+ ```~/books``` is a symlink to ```text/books```
+ from ```~/``` execute: ```git annex unlock books/foo```
+ which returns immediately with zero exit code and does not unlock foo.
What is the expected output? What do you see instead?
+ I expect ```~/text/books/foo`` to be unlocked
+ I think ```git annex unlock``` should resolve the symlinks and realize that this is a tracked file.
What version of git-annex are you using? On what operating system?
+ 3.20121112 in debian unstable
Please provide any additional information below.
+ I can unlock foo if I provide the full path, eg:
from ```~/``` execute: ```git annex unlock text/books/foo```
+ Interestingly, the following _does_ successfully unlock the file: ```cd ~/books && git annex unlock foo```
So it seems that symlinks in $PWD are being resolved, but not those in file paths passed as arguments.
Thank you, thank you!
- Jason
jason@jasonwoof.com
> I'm afraid this is not a bug. Here's why: If you run "git mv books/foo
> books/bar", git will complain:
>
>> fatal: not under version control, source=books/foo, destination=books/bar
>
> So git-annex is just following git's lead (indeed, it's just running
> `git ls-files` to find files to act on), and git doesn't
> recognise this path as a file that's in git. --[[Joey]]
+ Also, I think ```git annex unlock``` should emit an error message if a file explicitly addressed on the commandline can not be acted upon.
> I'm beginning to think perhaps it should. Users seem to find the current
> behavior to be sometimes confusing.
>
> However, it's actually a very difficult change to make. Several commands
> have multiple seek stages that act on different types of files, so
> any warning printed by an earlier stage may be premature if a later
> stage comes along and deals with a file. --[[Joey]]
>> Figured out a non-invasive way to add that warning. [[done]] --[[Joey]]
|
