From: Paolo \'Blaisorblade\' Giarrusso Date: Sun, 13 Nov 2005 19:42:25 +0000 (+0100) Subject: Stgit - gitmergeonefile.py: handle removal vs. changes X-Git-Tag: v0.14.3~557^2 X-Git-Url: https://git.distorted.org.uk/~mdw/stgit/commitdiff_plain/1780280ce740fd36b032ef6fc42feb34d1dd272b Stgit - gitmergeonefile.py: handle removal vs. changes I just got a "removal vs. changed" conflict, which is unhandled by StGit. That is taken from git-merge-one-file resolver, but is bad, as stg resolved does not handle unmerged entries (and probably it should be fixed too). Sample patch included, but some thought must be done on it (see the comments I left in). Signed-off-by: Paolo 'Blaisorblade' Giarrusso --- diff --git a/gitmergeonefile.py b/gitmergeonefile.py index 1cba193..9344d33 100755 --- a/gitmergeonefile.py +++ b/gitmergeonefile.py @@ -180,6 +180,30 @@ if orig_hash: os.remove(path) __remove_files() sys.exit(os.system('git-update-index --remove -- %s' % path)) + # file deleted in one and changed in the other + else: + # Do something here - we must at least merge the entry in the cache, + # instead of leaving it in U(nmerged) state. In fact, stg resolved + # does not handle that. + + # Do the same thing cogito does - remove the file in any case. + os.system('git-update-index --remove -- %s' % path) + + #if file1_hash: + ## file deleted upstream and changed in the patch. The patch is + ## probably going to move the changes elsewhere. + + #os.system('git-update-index --remove -- %s' % path) + #else: + ## file deleted in the patch and changed upstream. We could re-delete + ## it, but for now leave it there - and let the user check if he + ## still wants to remove the file. + + ## reset the cache to the first branch + #os.system('git-update-index --cacheinfo %s %s %s' + #% (file1_mode, file1_hash, path)) + __conflict() + # file does not exist in origin else: # file added in both