Felipe Contreras <felipe.contreras@xxxxxxxxx> writes: > I explored this a bit more and I've come to the conclusion that we > actually don't wand to discard the previous commits in the patch > series. Let's think about this example: > 0001 <- John > 0002 <- Me overriding some changes from John > > In this case we want John to appear in the CC list of 0002, because we > are changing his code. There are two cases: your patch partially overrides his code, and your patch completely rewrites/removes his code. Obviously in the former case you do want to Cc, but there are parts of his change that remain in the final result, so this case does not matter in this discussion. You will Cc him because of these remaining lines anyway. In the latter case, the only contribution that remains from him is a commit with his log message that does not help describing anything in the end result, cluttering the history. In such a case, I would imagine that the reviewers would want to see a cleaned up series that does not have his patch that is irrelevant for understanding the final result. John might want to know about it, if only to raise objection to the way how you arranged your series. For that reason, I think it makes sense to Cc him. But it is a rather a convoluted logic, if you ask me. You find John and Cc him, primarily so that he can point out that you should be redoing the series not to have his patch as an intermediate state in the series to begin with, because his commit does not contribute to the end result. It might make more sense if your tool told you about such a case directly, rather than helping you find John so that he can tell you ;-). -- 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