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
|
[[!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 at that
location; it's not present in that location, and fsck should avoid warning
when a key is dead in all locations. (A key that somehow had no locations
listed at all but still had a location log would also meet that crieria,
but that currently can't happen.)
If a key is dead in one location and alive in another location, it's still
alive. A key that was thought to be dead everywhere can come back alive,
eg, when a previously unknown remote that has the content is merged in.
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 last 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.
"""]]
|
