Paolo Bonzini <bonzini@xxxxxxx> writes: >> Because original E' was an amend of E, its log message explained >> everything E did and more. You cannot leave that same commit message in >> E''. What you did in E was already explained in the history, so now you >> would want to talk about the incremental change on top of it when you >> desribe E''. For that, replaying of E' must stop to allow you to fix up >> the log message. > > Yes, I had suggested in the original thread to follow up with a "git > rebase -i" to fix the commit message, because "git-rebase--interactive > --help" did not show a -s option. However, I found out that it does > support it, so it is probably better to use "git rebase -i -s theirs > --onto ..." directly. Yeah, but that is only about the commit log message. The issue of recording a wrong tree when commits X and Y exist is not alleviated, is it? > You mean that I should a) drop the example from git-rebase.1, b) > reword it to clarify it, c) drop the patch completely? I have to say that the rebase example is too misleading --- unless it is accompanied by a lot of disclaimers, its risk to give broken result to people probably is worse than the benefit. I am afraid that we would need a lot better use case to justify the use of "theirs" than what you wrote. I have occasionally seen valid situations to use "ours", but I personally haven't been in a situation that merge using "theirs" is a good solution. Obviously if you start from a wrong branch, you should be in the situation that you would want to merge using "theirs", just like when you started from the right branch and would use "ours", but in practice that never happened to me as far as I can recall. I am not sure where this asymmetry comes from. On the other hand, I've sometimes heard people say "when I get a merge conflict, I'd want to discard what I did _only in the conflicted part_." I am not sure if such a conflict resolution makes much sense in practice, but perhaps people know that their changes are worthless crap anyway, and do not even care about their work themselves, to the point that they would rather discard what they did than spend more time to fix them up properly. Whether that makes sense or not, what they want is different from "theirs" (which is opposite of "ours"); they want to keep their own changes for parts that did not conflict, and give up what they did only in the conflicted part. Perhaps such a kind of mixed conflict resolution should be supported under the name of "theirs", even though that would make "ours" and "theirs" _not_ the opposite of each other. I dunno... -- 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
