I think there's a bug in the squash behavior for git rebase -i. Say you've got the following history: aaaaa introduce an API bbbbb use the API in new code ccccc some unrelated review ddddd fix the API due to review And you do the following rebase: pick aaaaa introduce an API squash ddddd fix the API due to review pick bbbbb use the API in new code pick ccccc some unrelated review pick ddddd fix the API due to review (the last line being because some of the changes don't apply between a and b, so we want to duplicate the commit later, and probably squash it into b, but that's not part of this bug report) You get a conflict on the second item, which you expected. But when you resolve it, it squashes 3/5 into 2/5, not 2/5 into 1/5. I think this is because rebase --continue isn't noticing that it's a squash that needed help. It seems to work fine to do this in two steps (pick instead of squash, followed by another rebase that does the squash when it's unconflicted), as a workaround. -Daniel *This .sig left intentionally blank* - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
