From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Eric Sunshine <sunshine@sunshineco.com>
Cc: Junio C Hamano <gitster@pobox.com>,
Git List <git@vger.kernel.org>,
lucas.demarchi@intel.com, Stefan Beller <sbeller@google.com>,
Johannes Schindelin <johannes.schindelin@gmx.de>
Subject: Re: [PATCH] range-diff: add a --no-patch option to show a summary
Date: Tue, 06 Nov 2018 09:36:39 +0100 [thread overview]
Message-ID: <87d0ri7gbs.fsf@evledraar.gmail.com> (raw)
In-Reply-To: <CAPig+cR85-7wMYCGGFoRT3jSQzQmda_84Ox1kF6roa5j-1XZ0Q@mail.gmail.com>
On Tue, Nov 06 2018, Eric Sunshine wrote:
> On Mon, Nov 5, 2018 at 11:17 PM Junio C Hamano <gitster@pobox.com> wrote:
>> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>> > This change doesn't update git-format-patch with a --no-patch
>> > option. That can be added later similar to how format-patch first
>> > learned --range-diff, and then --creation-factor in
>> > 8631bf1cdd ("format-patch: add --creation-factor tweak for
>> > --range-diff", 2018-07-22). I don't see why anyone would want this for
>> > format-patch, it pretty much defeats the point of range-diff.
>>
>> Does it defeats the point of range-diff to omit the patch part in
>> the context of the cover letter? How?
>>
>> I think the output with this option is a good addition to the cover
>> letter as an abbreviated form (as opposed to the full range-diff,
>> whose support was added earlier) that gives an overview.
>
> I had the same response when reading the commit message but didn't
> vocalize it. I could see people wanting to suppress the 'patch' part
> of the embedded range-diff in a cover letter (though probably not as
> commentary in a single-patch).
>
>> Calling this --[no-]patch might make it harder to integrate it to
>> format-patch later, though. I suspect that people would expect
>> "format-patch --no-patch ..." to omit both the patch part of the
>> range-diff output *AND* the patch that should be applied to the
>> codebase (it of course would defeat the point of format-patch, so
>> today's format-patch would not pay attention to --no-patch, of
>> course). We need to be careful not to break that when it happens.
>
> Same concern on my side, which is why I was thinking of other, less
> confusing, names, such as --summarize or such, though even that is too
> general against the full set of git-format-patch options. It could,
> perhaps be a separate option, say, "git format-patch
> --range-changes=<prev>" or something, which would embed the equivalent
> of "git range-diff --no-patch <prev>...<current>" in the cover letter.
Maybe this was discussed more when this range-diff format-patch
integration was submitted, I wasn't following that closely:
Looking at this more carefully it seems like quite a design limitation
that we're conflating the options for format-patch itself and for the
range-diff invocation it makes.
Wouldn't it be better to make all these options
e.g. --range-diff-creation-factor=*, --range-diff-no-patch,
--range-diff-U1 etc. Now there's no way to say supply a different
-U<ctx> for the range-diff & the patches themselves which seems like a
semi-common use-case.
Doing that seems to be a matter of teaching setup_revisions() to
accumulate unknown options, then parsing those into their own diffopts
with the "range-diff-" prefix stripped and handing that data off to the
range-diff machinery, not the parsed options for range-diff itself as
happens now.
next prev parent reply other threads:[~2018-11-06 8:36 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-05 20:06 [PATCH] range-diff: add a --no-patch option to show a summary Ævar Arnfjörð Bjarmason
2018-11-05 20:26 ` Eric Sunshine
2018-11-05 21:00 ` Ævar Arnfjörð Bjarmason
2018-11-06 10:43 ` Johannes Schindelin
2018-11-06 16:01 ` Ævar Arnfjörð Bjarmason
2018-11-07 10:34 ` Johannes Schindelin
2018-11-07 10:43 ` Johannes Schindelin
2018-11-07 10:55 ` Johannes Schindelin
2018-11-07 11:08 ` Johannes Schindelin
2018-11-07 12:22 ` [PATCH v3 0/2] range-diff: doc + regression fix Ævar Arnfjörð Bjarmason
2018-11-07 12:22 ` [PATCH v3 1/2] range-diff doc: add a section about output stability Ævar Arnfjörð Bjarmason
2018-11-07 13:10 ` Stephen & Linda Smith
2018-11-07 22:52 ` Junio C Hamano
2018-11-07 19:06 ` Martin Ågren
2018-11-07 12:22 ` [PATCH v3 2/2] range-diff: fix regression in passing along diff options Ævar Arnfjörð Bjarmason
2018-11-08 17:08 ` Eric Sunshine
2018-11-08 22:34 ` Ævar Arnfjörð Bjarmason
2018-11-09 6:46 ` Eric Sunshine
2018-11-09 7:36 ` Ævar Arnfjörð Bjarmason
2018-11-09 10:18 ` [PATCH v4 0/3] range-diff fixes Ævar Arnfjörð Bjarmason
2018-11-09 16:32 ` Johannes Schindelin
2018-11-09 10:18 ` [PATCH v4 1/3] range-diff doc: add a section about output stability Ævar Arnfjörð Bjarmason
2018-11-09 10:18 ` [PATCH v4 2/3] range-diff: fix regression in passing along diff options Ævar Arnfjörð Bjarmason
2018-11-09 10:18 ` [PATCH v4 3/3] range-diff: make diff option behavior (e.g. --stat) consistent Ævar Arnfjörð Bjarmason
2018-11-09 13:25 ` Stephen & Linda Smith
2018-11-11 8:43 ` Eric Sunshine
2018-11-12 3:17 ` Junio C Hamano
2018-11-12 3:32 ` Junio C Hamano
2018-11-13 18:55 ` [PATCH v5 0/3] range-diff fixes Ævar Arnfjörð Bjarmason
2018-11-14 15:36 ` Johannes Schindelin
2018-11-13 18:55 ` [PATCH v5 1/3] range-diff doc: add a section about output stability Ævar Arnfjörð Bjarmason
2018-11-13 18:55 ` [PATCH v5 2/3] range-diff: fix regression in passing along diff options Ævar Arnfjörð Bjarmason
2018-11-13 18:55 ` [PATCH v5 3/3] range-diff: make diff option behavior (e.g. --stat) consistent Ævar Arnfjörð Bjarmason
2018-11-06 4:16 ` [PATCH] range-diff: add a --no-patch option to show a summary Junio C Hamano
2018-11-06 5:15 ` Eric Sunshine
2018-11-06 5:57 ` Junio C Hamano
2018-11-06 8:36 ` Ævar Arnfjörð Bjarmason [this message]
2018-11-06 16:24 ` [PATCH v2] " Ævar Arnfjörð Bjarmason
2018-11-07 0:57 ` Junio C Hamano
2018-11-07 11:11 ` Johannes Schindelin
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87d0ri7gbs.fsf@evledraar.gmail.com \
--to=avarab@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=johannes.schindelin@gmx.de \
--cc=lucas.demarchi@intel.com \
--cc=sbeller@google.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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).