bug
This commit is contained in:
parent
70a00802a6
commit
920794ab6b
1 changed files with 21 additions and 0 deletions
21
doc/bugs/direct_mode_merge_interrupt.mdwn
Normal file
21
doc/bugs/direct_mode_merge_interrupt.mdwn
Normal file
|
@ -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]]
|
Loading…
Add table
Reference in a new issue