Question

My Git repository has two files, alpha and beta, with identical content.

If I delete alpha in my master branch, and edit it in my feature branch, then when I merge master into feature, I’m warned about a conflict. Assume I resolve this by deleting alpha.

If I then rebase my feature branch onto master using git rebase master, alpha is deleted, but the changes I made to alpha on the feature branch are now applied to beta! I get a conflict warning but it’s happily resolved with an auto-merge without the commit being blocked for me to review.

Interestingly, if I do a git rebase -i and just accept the default, beta isn’t edited and I get to resolve the same conflict I resolved at merge time.

Three related questions then:

1. Why does Git think the change I applied to one file should be applied to another, when the other hasn’t been edited by any commit?
2. How can I avoid this sort of situation?
3. Why is the behaviour different for an interactive rebase, even when I take the default options?

I’m running Git 1.7.9 on Cygwin on Win7. I’ve put a transcript on pastebin showing this starting with a git init in an empty directory, if anyone wants to see the details for themselves (I’m not posting it here due to length).

Answer 1

From the documentation for git-rebase:

-m
–merge
Use merging strategies to rebase. When the recursive (default) merge strategy is used, this allows rebase to be aware of renames on the upstream side.

When a file is deleted, Git considers that a candidate for a rename, and tries to apply the rebased patch to the corresponding renamed file. It sounds like it might have made a poor guess in your case.

You can use the -m option to select a different merge strategy. For example, the resolve merge strategy may avoid this problem with auto-detecting renames (see git-merge for details on merge strategies).