From: Eric Sunshine <sunshine@sunshineco.com>
To: "Nguyễn Thái Ngọc Duy" <pclouds@gmail.com>
Cc: "Git List" <git@vger.kernel.org>,
"Johannes Schindelin" <Johannes.Schindelin@gmx.de>,
"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
"Stefan Beller" <sbeller@google.com>
Subject: Re: [PATCH 06/14] format-patch: allow --interdiff to apply to a lone-patch
Date: Mon, 23 Jul 2018 15:46:57 -0400 [thread overview]
Message-ID: <CAPig+cR=rcoLqtefWJMe0NY_7OX7WR6q1UoF-HnYrHZWtKuHAw@mail.gmail.com> (raw)
In-Reply-To: <CACsJy8Aw6R8-3kDfhCqunXziajCg9O_1WrEYc4rfKa+-=m1D5g@mail.gmail.com>
On Mon, Jul 23, 2018 at 12:22 PM Duy Nguyen <pclouds@gmail.com> wrote:
> On Sun, Jul 22, 2018 at 11:58 AM Eric Sunshine <sunshine@sunshineco.com> wrote:
> > + if (cmit_fmt_is_mail(ctx.fmt) && opt->idiff_oid1) {
>
> OK putting idiff stuff in rev_info is probably the right choice. But
> we all three fields prefixed with idiff_, maybe you could just add a
> new struct "idiff_options" to contain them and add a pointer to that
> struct in rev_info. Then "opt->idiff" is enough to know if idiff is
> requested instead of relying on idiff_oid1 (seems too random).
I have mixed feelings about this suggestion for the following reasons:
* 'struct rev_info' already contains a number of specialized fields
which apply in only certain use cases but not others, and those fields
often are grouped textually to show relationship rather than being
bundled in a struct.
* These new fields are very specific to this particular operation and
are unlikely to ever have wider use, so adding the extra level of
indirection/abstraction (whatever you'd call it) feels overkill and,
while nice theoretically, adds complexity without much practical
value.
* Bundling these fields in a struct might incorrectly imply to readers
that these items, collectively, can be used in some general-purpose
fashion, which isn't at all the case; they are very specific to this
operation and that struct would never be used elsewhere or for any
other purpose.
The upside of bundling them in a struct, as you mention, is that
"opt->idiff" would be slightly more obvious than "opt->idiff_oid1" as
a "should we print an interdiff?" conditional. On the other hand, this
case is so specific and narrow that I'm not sure it warrants such
generality.
next prev parent reply other threads:[~2018-07-23 19:47 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-22 9:57 [PATCH 00/14] format-patch: add --interdiff and --range-diff options Eric Sunshine
2018-07-22 9:57 ` [PATCH 01/14] format-patch: allow additional generated content in make_cover_letter() Eric Sunshine
2018-07-22 9:57 ` [PATCH 02/14] format-patch: add --interdiff option to embed diff in cover letter Eric Sunshine
2018-07-22 10:31 ` Eric Sunshine
2018-07-23 16:02 ` Duy Nguyen
2018-07-23 19:18 ` Eric Sunshine
2018-07-23 21:36 ` Junio C Hamano
2018-07-22 9:57 ` [PATCH 03/14] format-patch: teach --interdiff to respect -v/--reroll-count Eric Sunshine
2018-07-23 16:12 ` Duy Nguyen
2018-07-23 19:32 ` Eric Sunshine
2018-07-22 9:57 ` [PATCH 04/14] interdiff: teach show_interdiff() to indent interdiff Eric Sunshine
2018-07-22 9:57 ` [PATCH 05/14] log-tree: show_log: make commentary block delimiting reusable Eric Sunshine
2018-07-22 9:57 ` [PATCH 06/14] format-patch: allow --interdiff to apply to a lone-patch Eric Sunshine
2018-07-23 16:22 ` Duy Nguyen
2018-07-23 19:46 ` Eric Sunshine [this message]
2018-07-22 9:57 ` [PATCH 07/14] range-diff: respect diff_option.file rather than assuming 'stdout' Eric Sunshine
2018-07-23 22:59 ` Stefan Beller
2018-07-23 23:20 ` Eric Sunshine
2018-07-25 18:25 ` Junio C Hamano
2018-07-22 9:57 ` [PATCH 08/14] range-diff: publish default creation factor Eric Sunshine
2018-07-22 9:57 ` [PATCH 09/14] range-diff: relieve callers of low-level configuration burden Eric Sunshine
2018-07-22 9:57 ` [PATCH 10/14] format-patch: add --range-diff option to embed diff in cover letter Eric Sunshine
2018-07-23 16:28 ` Duy Nguyen
2018-07-23 19:58 ` Eric Sunshine
2018-07-25 17:29 ` Junio C Hamano
2018-07-25 19:30 ` Eric Sunshine
2018-07-25 20:32 ` Junio C Hamano
2018-07-25 17:38 ` Duy Nguyen
2018-07-22 9:57 ` [PATCH 11/14] format-patch: extend --range-diff to accept revision range Eric Sunshine
2018-07-25 20:53 ` Junio C Hamano
2018-09-07 9:15 ` Eric Sunshine
2018-07-22 9:57 ` [PATCH 12/14] format-patch: teach --range-diff to respect -v/--reroll-count Eric Sunshine
2018-07-22 9:57 ` [PATCH 13/14] format-patch: add --creation-factor tweak for --range-diff Eric Sunshine
2018-07-22 9:57 ` [PATCH 14/14] format-patch: allow --range-diff to apply to a lone-patch Eric Sunshine
2018-07-25 21:07 ` Junio C Hamano
2018-09-07 8:46 ` Eric Sunshine
2018-07-23 16:32 ` [PATCH 00/14] format-patch: add --interdiff and --range-diff options Duy Nguyen
2018-07-23 20:03 ` Eric Sunshine
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='CAPig+cR=rcoLqtefWJMe0NY_7OX7WR6q1UoF-HnYrHZWtKuHAw@mail.gmail.com' \
--to=sunshine@sunshineco.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=avarab@gmail.com \
--cc=git@vger.kernel.org \
--cc=pclouds@gmail.com \
--cc=sbeller@google.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).