From: Junio C Hamano <gitster@pobox.com>
To: Eric Sunshine <sunshine@sunshineco.com>
Cc: Jonathan Nieder <jrnieder@gmail.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
Git List <git@vger.kernel.org>
Subject: Re: [PATCH v2] contrib: git-cpcover: copy cover letter
Date: Wed, 04 Dec 2019 09:07:08 -0800 [thread overview]
Message-ID: <xmqqd0d458ar.fsf@gitster-ct.c.googlers.com> (raw)
In-Reply-To: <CAPig+cREF8BSVbCoOUaRMPOyfD_bfD5PhxgM4QZgot7sziCNug@mail.gmail.com> (Eric Sunshine's message of "Wed, 4 Dec 2019 11:32:20 -0500")
Eric Sunshine <sunshine@sunshineco.com> writes:
> On Wed, Dec 4, 2019 at 11:23 AM Junio C Hamano <gitster@pobox.com> wrote:
>> Eric Sunshine <sunshine@sunshineco.com> writes:
>> > I could even imagine a new option -V<n> which has the combined effect
>> > of setting the re-roll count (like -v) and automagically copying the
>> > cover letter material from cover letter v<n-1> located in <dir>.
>>
>> I actually looked into doing something similar but without any new
>> option (i.e. unconditionally --cover-letter with -v<n> would check
>> for v<n-1>-0000-cover.letter and does the right thing) some time
>> ago.
>
> Yes, I like that better than a new option, and wanted to suggest it as
> well, however... (see below)
>
>> But I think that was even before we integrated the range-diff stuff,
>> which does seem to use the "given we are doing <n>, let's compare
>> with <n-1>" thing, so perhaps it is not too difficult.
>
> Yup.
>
>> I am just saying that I think the change would not have to be opt-in,
>> but can be unconditionally made, simply because replacing the BLURB
>> HERE placeholder with *anything* written by human user previously is
>> a 100% improvement ;-)
>
> I had started writing the same in my previous reply but then realized
> that it could break existing tooling which uses -v and --cover-letter
> together and which searches for the well-known BLURB HERE placeholder
> to replace it automatically. If I'm wrong about possibly breaking
> existing tooling, then I'd also vote for this behavior kicking in
> automatically with -v and --cover-letter specified together.
Well, they can now disable that "copy over the material from the
previous" step, which is good. I actually think we should add the
well-known BLURB HERE string *after* populating the new version of
the coer letter with the materials from old one to *force* users to
proofread and adjust it to the updated reality, so if that happens,
then the existing tooling would also work as before ;-)
next prev parent reply other threads:[~2019-12-04 17:07 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-03 20:13 [PATCH v2] contrib: git-cpcover: copy cover letter Michael S. Tsirkin
2019-12-04 4:44 ` Jonathan Nieder
2019-12-04 5:18 ` Eric Sunshine
2019-12-04 16:22 ` Junio C Hamano
2019-12-04 16:32 ` Eric Sunshine
2019-12-04 17:07 ` Junio C Hamano [this message]
2019-12-09 15:49 ` Michael S. Tsirkin
2019-12-04 6:58 ` Denton Liu
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=xmqqd0d458ar.fsf@gitster-ct.c.googlers.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=jrnieder@gmail.com \
--cc=mst@redhat.com \
--cc=sunshine@sunshineco.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.