From: Felipe Contreras <felipe.contreras@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: My custom cccmd
Date: Fri, 30 Oct 2009 10:39:18 +0200 [thread overview]
Message-ID: <94a0d4530910300139l2f20e3aaw2f89e0b809a7246c@mail.gmail.com> (raw)
In-Reply-To: <7vzl7c4i81.fsf@alter.siamese.dyndns.org>
On Tue, Oct 27, 2009 at 11:53 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> 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 ;-).
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?
--
Felipe Contreras
next prev parent reply other threads:[~2009-10-30 8:39 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-15 13:20 My custom cccmd Felipe Contreras
2009-10-15 20:09 ` Junio C Hamano
2009-10-15 21:37 ` Felipe Contreras
2009-10-25 15:04 ` Felipe Contreras
2009-10-27 21:53 ` Junio C Hamano
2009-10-30 8:39 ` Felipe Contreras [this message]
2009-10-30 21:52 ` Junio C Hamano
2009-11-02 14:25 ` Felipe Contreras
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=94a0d4530910300139l2f20e3aaw2f89e0b809a7246c@mail.gmail.com \
--to=felipe.contreras@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).