Re: My custom cccmd

Felipe Contreras [off-list ref] writes:

On Tue, Oct 27, 2009 at 11:53 PM, Junio C Hamano [off-list ref] wrote:

quoted

Felipe Contreras [off-list ref] writes:

quoted

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 [off-list ref] wrote:

On Thu, Oct 15, 2009 at 11:09 PM, Junio C Hamano [off-list ref] wrote:

quoted

 #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.