resolvemerge: Improve cleanup of files that were deleted by one side of a conflicted...

This case was handled by cleanConflictCruft, but only when the annexed
file's object was present. When not present, it left the annexed file
with the original name, not checked into git, while adding the variant
file. So, add an explicit deletion of the deleted file in this case.

My specific case where this happened actually involves
merge.directoryRenames=conflict. After a merge involving that,
the situation was the file appears as "added by them", because that
caused the file that they added to be moved into a directory we renamed.

That case is the same as them adding a modified version of the file,
while we deleted it. (Except for the history of the file, since it's a
new file, but this doesn't look at history.)

This commit was sponsored by Boyd Stephen Smith Jr. on Patreon.

diff --git a/Annex/AutoMerge.hs b/Annex/AutoMerge.hs
index 5e60fc9f93c40123cfc93b3c45d05641e2d9f5b8..7680a26da228762cb67396e8909eeddda05feaf5 100644 (file)
--- a/Annex/AutoMerge.hs
+++ b/Annex/AutoMerge.hs
@@ -175,11 +175,15 @@ resolveMerge' unstagedmap (Just us) them inoverlay u = do
                (Right Nothing, Right Nothing) -> cannotresolve
                -- Other side deleted the file, our side is an annexed
                -- file. Make it a variant.
-               (Right (Just keyUs), Left ()) -> resolveby [keyUs] $
+               (Right (Just keyUs), Left ()) -> resolveby [keyUs] $ do
+                       unless inoverlay $
+                               liftIO $ nukeFile file
                        makevariantannexlink keyUs LsFiles.valThem
                -- Our side deleted the file, other side is an annexed
                -- file. Make it a variant.
-               (Left (), Right (Just keyThem)) -> resolveby [keyThem] $
+               (Left (), Right (Just keyThem)) -> resolveby [keyThem] $ do
+                       unless inoverlay $
+                               liftIO $ nukeFile file
                        makevariantannexlink keyThem LsFiles.valThem
                -- One side deleted the file, other side is not an annexed
                -- file; cannot resolve.

diff --git a/CHANGELOG b/CHANGELOG
index e2a88941cd7ac4547ae2c819cb33c196ec41410d..ed7d4f8a84222929b5f2ba607c6b2abe8b1ad660 100644 (file)
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -31,6 +31,8 @@ git-annex (8.20200815) UNRELEASED; urgency=medium
     behavior that git-annex has had for a long time.
   * Retry transfers to exporttree=yes remotes same as for other remotes.
   * import: Retry downloads that fail, same as is done for downloads generally.
+  * resolvemerge: Improve cleanup of files that were deleted by one side of
+    a conflicted merge, and modified by the other side.
 
  -- Joey Hess <id@joeyh.name>  Fri, 14 Aug 2020 14:57:45 -0400
 

diff --git a/doc/bugs/new_merge.directoryRenames_behavior_breaks_sync_merge_conflict_resolution.mdwn b/doc/bugs/new_merge.directoryRenames_behavior_breaks_sync_merge_conflict_resolution.mdwn
index ca42126bf00ea1f2de36a08813e9c18c99c34935..0adbf07481ada78a6aa9833b1a62c64e3e90cc44 100644 (file)
--- a/doc/bugs/new_merge.directoryRenames_behavior_breaks_sync_merge_conflict_resolution.mdwn
+++ b/doc/bugs/new_merge.directoryRenames_behavior_breaks_sync_merge_conflict_resolution.mdwn
@@ -39,3 +39,10 @@ produced by case, so it might be possible for git-annex to use that
 to detect it and handle it specially.
 
 --[[Joey]]
+
+> Fixed the file not being checked in. In fact, it needed to be cleaned up.
+> 
+> That avoids part of the problem. To avoid the surprising rename,
+> git-annex sync should set merge.directoryRenames=false when
+> merge.directoryRenames is not configured, unless automatic merge conflict
+> resolution is disabled. --[[Joey]]