Felipe Contreras <felipe.contreras@xxxxxxxxx> writes: > On Tue, Oct 27, 2009 at 11:53 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >> 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. >> ... >> 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 ;-). > > But that's not the purpose of the cccmd tool. > > I agree that such "patch series simplificator" tool would be very > useful, but that's out of scope for this. Isn't it? Exactly. So you agree that you _do_ want to "discard the previous commits in the patch series", because not doing so would mean the result would be a half-cooked "patch series simplificator" that tries to do something that is outside the scope of cccmd, right? The "discarding the previous commits" happens to match what I suggested earlier that lead to your "explored this a bit more": On Thu, Oct 15, 2009 at 11:37 PM, Felipe Contreras <felipe.contreras@xxxxxxxxx> wrote: > On Thu, Oct 15, 2009 at 11:09 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >> #2. If you have two patch series that updates one file twice, some >> changes in your second patch could even be an update to the changes >> you introduced in your first patch. After you fix issue #1, you >> would probably want to fix this by excluding the commits you have >> already sent the blames for. so I think we are in agreement. -- 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