diff options
| author |  Joey Hess <joeyh@joeyh.name> | 2015-06-09 13:39:35 -0400 |
|---|---|---|
| committer | Joey Hess <joeyh@joeyh.name> | 2015-06-09 13:39:35 -0400 |
| commit | b74d1afc86eb5e2684ac1b41e5ff7dd3900e1ae4 (patch) | |
| tree | 7d3971b1ba5da673f6c40fc647bc324cdb0e82f5 /doc | |
| parent | 6cc01e97fff6fcb933c3dba8fb008df9909bc390 (diff) | |
better semantics
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/bugs/fsck_reports_unsolvable_problem/comment_2_d32d4cd471632f63db681f3495039b00._comment | 17 |
1 files changed, 9 insertions, 8 deletions
diff --git a/doc/bugs/fsck_reports_unsolvable_problem/comment_2_d32d4cd471632f63db681f3495039b00._comment b/doc/bugs/fsck_reports_unsolvable_problem/comment_2_d32d4cd471632f63db681f3495039b00._comment index 2a08e3e2b..1fa08f39c 100644 --- a/doc/bugs/fsck_reports_unsolvable_problem/comment_2_d32d4cd471632f63db681f3495039b00._comment +++ b/doc/bugs/fsck_reports_unsolvable_problem/comment_2_d32d4cd471632f63db681f3495039b00._comment @@ -30,19 +30,20 @@ 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. +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.) -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.) +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 lat copy, they don't need fsck +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 |