A file was deleted somewhere along the topic branch, and later the deleting commit was reverted. Now the master branch modified that file, and this causes "modified/deleted" conflict on the deleting commit when rebasing. Assume further that the deleting commit (and therefore its revert too) also contained other unrelated changes: the deletion and its revert unfortunately aren't isolated.

Am I correct in assuming that if I accept the deleting commit and its revert (i.e. resolve both in favor of the topic branch), then I will end up with the old version of the file, with master changes lost?

What is the simplest way to handle this situation without losing master changes? Is -i avoidable?

(It must be a rebase, merging is out of consideration).

CodePudding user response：

The short answer

Yes, you are correct: if you resolve the "modified/deleted" conflict by deleting the file, you will lose the changes from master.

One strategy: keep the changed file when you resolve the conflict.

If you want to do this rebase operation without using -i, you can make sure the commit that re-introduces the deleted file also has a conflict, by resolving the "modified/deleted" conflict in favour of the modified version.

If it's not too illogical for your code base for that file to never have been deleted, then just don't delete it in that rebased delete commit: keep the version with the modifications from master.

When the rebase operation hits the commit that brings the file back in, it will report a conflict for having added a file that was already there. Again, resolve it by keeping the modifications from master, and you should be set.

The simplest solution is indeed rebase -i in my opinion.

To be honest, I think the solution that would be the least work for you would be to rebase -i onto master, and edit the commit that reintroduces the file, which will give you a chance to manually set it to the version from master.

General thoughts

I'm confident there does not exist a solution that can do it all automatically for you: there is a genuine conflict between master and this branch, which you must resolve somehow, with -i, with my first strategy above, or maybe by first modifying the branch (again with rebase -i) to not have deleted the file in the first place.