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
|
[[!comment format=mdwn
username="joey"
subject="""comment 2"""
date="2015-06-09T16:59:22Z"
content="""
Had a closer look at using a transition for this. It would mean that, when
merging with any repo that has not made the transition yet, that repo would
need to be modified to remove log files for keys that are no longer present
anywhere. Without a list of exactly which keys, the transition could take
out files, as it spreads, that were not the ones originally desired to be
ignored.
So, I think that and the branch rewriting overhead of transitions both make
a transition not a desirable way to handle this.
Seems like the best way, then, is a log file where keys can be listed that
are known gone and that fsck should shut up about. Although there could be
scalability problems to listing them all in a single file, which would all
need to be loaded into memory by fack.
Or, could have separate files per key, but that adds another query to every
key fsck processes.
Or, the location log format could be extended, to add a flag to indicate
when fsck should ignore a given key. This adds some complexity to file
formats, but it seems like the best choice.
Could extend the 1/0 in the log to add a third value for "ignore this".
Turns out that putting eg 'X' there doesn't break any old versions of
git-annex; they ignore the unparsable line, and the result is the same as a
'0' line; the key is not present in the specified location.
So, if there's an 'X', it means the key is thought to be dead; it's not
present in that location, and fsck should ignore when its content is
entirely missing.
It would, probably, also make sense for fsck to detect when a key has
location indication for both dead and present, and convert the
'X' to an '0', since the content has stopped being entirely missing.
(Eg, when a previously unknown remote that has the content becomes available.)
As to the UI for this, it could be added to `git annex forget` or a new
command. It would also be possible for `drop --force` to automatically set
the dead flag when it removed the last copy of a key. Seems like, if the
user has requested a forced drop of the lat copy, they don't need fsck
telling them about it later.
I think that only fsck --all (or in a bare repo) should ignore dead keys
though. If a git work tree has files that point to dead keys, fsck should
still complain.
"""]]
|
