avoid bad commits after interrupted direct mode sync (or merge)

It was possible for a interrupted sync or merge in direct mode to
leave the work tree out of sync with the last recorded commit.
This would result in the next commit seeing files missing from the work
tree, and committing their removal.

Now, a direct mode merge happens not only in a throwaway work tree, but using
a temporary index file, and without any commits or index changes
being made until the real work tree has been updated. If the merge is
interrupted, the work tree may have some updated files, but worst case a
commit will redundantly commit changes that come from the merge.

This commit was sponsored by Tony Cantor.

1 files changed, 23 insertions, 3 deletions

diff --git a/doc/bugs/direct_mode_merge_interrupt.mdwn b/doc/bugs/direct_mode_merge_interrupt.mdwn
index 50b32929b..e64848140 100644
--- a/doc/bugs/direct_mode_merge_interrupt.mdwn
+++ b/doc/bugs/direct_mode_merge_interrupt.mdwn
@@ -17,10 +17,30 @@ mode repo can get them back.
 To fix this, direct mode merge would need to avoid updating the current
 branch when merging the remote branch into it (how?). It should first
 update the whole work tree, and only after it's updated should it update
-the current branch to reflect the merge. (I assume this is how `git merge`
-normally works.) --[[Joey]]
+the index and the current branch to reflect the merge.  
+
+This way, if the merge is interrupted, the work tree may have uncommitted
+changed -- but it's fine if they get accidentially committed, since when
+the merge is re-done, those changes will by the same ones made by the
+merge. (I assume this is how `git merge` normally works.) --[[Joey]]
 
 > Implemented that. And then realized that even updating the index
 > as part of a merge results in the work tree being out of sync with the
 > index. Which will cause the next sync to again delete any files that
-> are in the index but not the work tree. Urgh. --[[Joey]]
+> are in the index but not the work tree. Urgh. 
+> 
+> Seems that a direct mode
+> merge also needs to use a different index file to stage its changes?
+> (Ugh)
+> > [[done]] --[[Joey]]
+> 
+> Or could perhaps use `git-merge-tree`
+> and avoid staging the merge in the index until the work-tree is updated.
+> 
+> Alternatively, could use another strategy.. Add a lock file which is held while 
+> the merge is in progress and contains the pre-merge sha.
+> If the lock file is present but not held, state is inconsistent.
+> `git-annex sync` and the SanityChecker should
+> then run mergeDirectCleanup to recover, before any commits can be made
+> from the inconsistent state. This approach seems to get complicated
+> quickly.. --[[Joey]]