blob: e4a364195e477acef964c6f9c8decc555f6da07d (
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
|
### Please describe the problem.
There are a lot of differences in the behaviour of usual commands and commans using --all.
The specific problem I found was that "git annex fsck --all" will only checksum it seems and not report back numcopies failures.
Checking if objects/old versions have propagated is not possible without it or do I miss something.
(As additional note not sure if related. It seems that git annex fsck --all is running much faster in my tests 1/3 faster. Any reason for that? Bug related?)
### What steps will reproduce the problem?
compare "git annex fsck" vs "git annex fsck" (no numcopies check)
### What version of git-annex are you using? On what operating system?
git-annex version: 5.20140210-gd99db49
Linux (Ubuntu 13.10)
### Please provide any additional information below.
[[!format sh """
# If you can, paste a complete transcript of the problem occurring here.
# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
# End of transcript or log.
"""]]
> It's expected that --all (and --unused) make .gitattributes
> annex.numcopies settings be ignored, because with these options git-annex
> is operating on keys, it does not know or care what filename they're
> associated with, and so cannot look them up in .gitattributes. I have
> improved the documentation of .gitattributes files to mention this
> limitation.
>
> I also notice that fsck --all is not checking .git/config's
> annex.numcopies or the new global numcopies setting. It certianly makes
> sense for those numcopies settings to be paid attention to.
> [[fixed|done]] --[[Joey]]
>
> (--all is faster because it can quickly scan through .git/annex/objects
> to find everything, rather than looking at the symlink target of every
> file in the work tree.)
|
