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
54
55
56
|
### Please describe the problem.
If you `git annex edit FILE`, an already-committed file, then do `git annex sync`, FILE will be added to .git/objects, but can be cleaned up with `git prune`. An annoyance, but not a huge problem.
> This is why you're recommended to use `git add` after you're done
> changing unlocked files. This avoids the git commit staging the file
> in the index, even though the pre-commit hook fixes that up. It does
> indeed leave the file contents in .git/objects, although with no refs
> pointing to it, `git prune` will delete it sooner or later. --[[Joey]]
If, on the other hand, you do git annex add, then edit, then sync, it will actually be committed to the git repository. Fixing that is a lot less trivial than `git prune`.
> This is indeed a problem..
### What steps will reproduce the problem?
anthony@Watt:/tmp/test$ du -sh .git/objects/
24K .git/objects/
anthony@Watt:/tmp/test$ dd if=/dev/urandom bs=$[1024*1024] count=100 of=100mb-3
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 6.08718 s, 17.2 MB/s
anthony@Watt:/tmp/test$ git annex add 100mb-3
add 100mb-3 ok
(Recording state in git...)
anthony@Watt:/tmp/test$ git annex edit 100mb-3
unlock 100mb-3 (copying...) ok
anthony@Watt:/tmp/test$ git annex sync
commit ok
anthony@Watt:/tmp/test [$?=130]$ git prune
anthony@Watt:/tmp/test$ du -sh .git/objects/
101M .git/objects/
anthony@Watt:/tmp/test$ ls -l 100mb-3
-rw-r--r-- 1 anthony anthony 104857600 Jan 1 13:41 100mb-3
### What version of git-annex are you using? On what operating system?
5.20141125 on Debian testing/unstable
> Analysis: This only happens when a file is added and then unlocked
> without first being committed.
>
> In this situation, the file has a typechange between the index and
> the working tree. However, by the time the pre-commit hook gets
> run, git commit has already staged the unlocked file content into the
> index. So, there is nolonger a typechange between the index and the work
> tree. And, since the file is new, there is no typechange between the
> index and last commit either. The latter is what the pre-commit hook
> looks for.
>
> Conclusion: The pre-commit hook cannot possibly detect this situation.
> Instead, it seems the only way to block the problem is to prevent
> unlocking a file that does not have any git history.
>
> And I've [[done]] that now. --[[Joey]]
|
