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:
- 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?
- How can I avoid this sort of situation?
- 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).