full design

doc/bugs/fsck_reports_unsolvable_problem/comment_2_d32d4cd471632f63db681f3495039b00._comment

@@ -0,0 +1,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.
+"""]]