Following on the scenario from this question, I'm performing a git rebase -s recursive -X theirs etc... and am surprised to be stopped with the following types of conflicts:
- added by them
- deleted by them
- deleted by us
Is there some reason the strategy doesn't cope with these?
(I don't know if this is significant, but git doesn't report conflicts in the output, it just says When you have resolved this problem run "git rebase --continue")
UPDATE Here's a script that doesn't quite reproduce, but nearly:
git init
git symbolic-ref HEAD refs/heads/Branch1 #just to get the 'right' branch name
echo Added in A > DeletedByThem.txt
git add -A
git commit -m A
echo Modified in B >> DeletedByThem.txt
git add -A
git commit -m B
echo Modified in C >> DeletedByThem.txt
echo Added in C > DeletedByUs.txt
git add -A
git commit -m C
git checkout -b Branch2
echo Modified in D >> DeletedByUs.txt
git rm DeletedByThem.txt
git add -A
git commit -m D
echo Modified in E >> DeletedByUs.txt
git add -A
git commit -m E
At this point, you should have this:
Branch1: A - B - C
\
Branch2: D - E
What we want is this:
Branch1: A - B - C
\
Branch2: D - E
So:
git rebase -s recursive -X theirs --onto [SHA of B] Branch1 Branch2
This reproduces the 'deleted by them' and 'deleted by us' problems, but doesn't reproduce the 'added by them', nor the absence of any conflict report.
From what I can gather, in this context 'deleted by them' thus means "modified after B, then deleted" (so we do want to delete it in Branch2), and "deleted by us" means "created after B" (so we want to keep it in Branch2)
From what I can tell from the history of my real (and enormous) repo, the 'added by them' is related to incorrectly detected renames (i.e. identical files in completely different folders being identified as renames).
