summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--doc/bugs/direct_mode_merge_interrupt.mdwn21
1 files changed, 21 insertions, 0 deletions
diff --git a/doc/bugs/direct_mode_merge_interrupt.mdwn b/doc/bugs/direct_mode_merge_interrupt.mdwn
new file mode 100644
index 000000000..a3b640a8c
--- /dev/null
+++ b/doc/bugs/direct_mode_merge_interrupt.mdwn
@@ -0,0 +1,21 @@
+Seems to me there is a bug in how merges are done in direct mode. This is
+done in two steps:
+
+1. Merge the remote branch into the local branch, with work tree directed
+ to a temp dir.
+2. Use the temp dir and the newly merged branch to update the work tree.
+
+If this is interrupted between 1 and 2, by eg the user ctrl-Cing or power
+being lost, the result is a repository that thinks the current branch has
+been merged, but does not have an updated work tree. The next sync in that
+repository will see the files as deleted (or as being an old version), and
+commit the current work tree state to the branch.
+
+Result is files appear to be lost, although `git revert` in an indirect
+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]]