git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

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