git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Elijah Newren <newren@gmail.com>
To: Sergey Organov <sorganov@gmail.com>
Cc: "Junio C Hamano" <gitster@pobox.com>, "Jeff King" <peff@peff.net>,
	"Philip Oakley" <philipoakley@iee.email>,
	"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
	"Alex Henrie" <alexhenrie24@gmail.com>,
	"Jonathan Nieder" <jrnieder@gmail.com>,
	"huang guanlong" <gl041188@gmail.com>,
	git@vger.kernel.org
Subject: Re: [PATCH 0/5] diff-merges: more features
Date: Mon, 28 Nov 2022 20:50:45 -0800	[thread overview]
Message-ID: <CABPp-BHaPpQdO-uBT6ENHAM1Y-c=SBxktH-S_BTtxJvfd1qSpw@mail.gmail.com> (raw)
In-Reply-To: <20221127093721.31012-1-sorganov@gmail.com>

On Sun, Nov 27, 2022 at 1:37 AM Sergey Organov <sorganov@gmail.com> wrote:
>
> 1. --diff-merges=[no]-hide

This seems problematic to me.  Currently, all the options to
diff-merges are exclusive of each other; the user is picking one of
them to determine how to format diffs for merges.  Now you are
introducing the ability to combine various options, leading users to
think that perhaps they can run with all three of
`--diff-merges=combined-dense --diff-merges=remerge
--diff-merges=separate` or other nonsensical combinations.  Shouldn't
this [no-]hide stuff be a separate flag rather than reusing
--diff-merges?

> The set of diff-merges options happened to be incomplete, and failed
> to implement exact semantics of -m option that hides output of diffs
> for merge commits unless -p option is active as well.
>
> The new "hide" option fixes this issue, so that now
>
>   --diff-merges=on --diff-merges=hide
>
> combo is the exact synonym for -m.

Why is completeness important here?  Perhaps I should state this
another way: when would users ever want to use this new "hide" option?
 I got through your cover letter not knowing the answer to this, but
was hoping it'd at least be covered in one of your commit messages or
documentation changes.  Maybe it was there, but I somehow missed it.

Is the only goal some sense of developer completeness for these
options, or are these end-user-facing options of utility to actual end
users?  I'm hoping the latter, but if so, can that be documented and
explained somewhere?  I'm pretty sure this is explained somewhere in
an old mailing list discussion, but where?

> The log.diffMerges configuration also accepts "hide" and "no-hide"
> values, and governs the default value for the hide bit. The
> configuration behaves as if "--diff-merges=[no-]hide" is inserted
> first in the command-line.
>
> 2. log.diffMerges-m-imply-p
>
> Historically, '-m' doesn't imply '-p' whereas similar '-c' and '--cc'
> options do. Simply fixing this inconsistency by unconditional
> modification of '-m' semantics appeared to be a bad idea, as it broke
> some legacy scripts/aliases. This patch rather provides configuration
> variable to tweak '-m' behavior accordingly.

> 3. log.diffMergesForce
>
> Force specific log format for -c, --cc, and --remerge-diff options
> instead of their respective formats. The override is useful when some
> external tool hard-codes diff for merges format option.

Why just these three options and not -m (or --diff-merges=separate)?

Also, I read this and didn't quite fully grasp the intent; your
explanation in response to Junio seemed much more enlightening.
Perhaps the wording/explanation could be cleaned up a bit?  I'll
comment more on that specific patch...

> 4. Support list of values for --diff-merges
>
> This allows for shorter --diff-merges=on,hide forms.

And thus making users think they can pass
--diff-merges=combined-dense,remerge,separate and suspecting that
it'll do something useful?  Seems like this is reinforcing a mistake
to me.


> 5. Issue warning for lone '-m'.
>
> Lone '-m' is in use by scripts/aliases that aim at enabling diff
> output for merge commits, but only if '-p' is then specified as well.
>
> As '-m' may now be configured to imply '-p' (using
> 'log.diffMerges-m-imply-p'), issue warning if lone '-m' is specified,
> and suggest to instead use '--diff-merges=on,hide' that does not
> depend on user configuration.
>
> This is expected to give a provision for enabling
> log.diffMerges-m-imply-p by default in the future.
>
> Sergey Organov (5):
>   diff-merges: implement [no-]hide option and log.diffMergesHide config
>   diff-merges: implement log.diffMerges-m-imply-p config
>   diff-merges: implement log.diffMergesForce config
>   diff-merges: support list of values for --diff-merges
>   diff-merges: issue warning on lone '-m' option
>
>  Documentation/config/log.txt                  |  20 ++++
>  Documentation/diff-options.txt                |  20 +++-
>  builtin/log.c                                 |   6 +
>  diff-merges.c                                 | 108 +++++++++++++++---
>  diff-merges.h                                 |   6 +
>  t/t4013-diff-various.sh                       |  89 ++++++++++++++-
>  ...ges=first-parent_--diff-merges=hide_master |  34 ++++++
>  t/t9902-completion.sh                         |   9 ++
>  8 files changed, 272 insertions(+), 20 deletions(-)
>  create mode 100644 t/t4013/diff.log_--diff-merges=first-parent_--diff-merges=hide_master
>
> --
> 2.37.3.526.g5f84746cb16b
>

  parent reply	other threads:[~2022-11-29  4:51 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-27  9:37 [PATCH 0/5] diff-merges: more features Sergey Organov
2022-11-27  9:37 ` [PATCH 1/5] diff-merges: implement [no-]hide option and log.diffMergesHide config Sergey Organov
2022-12-08  0:06   ` Glen Choo
2022-12-08 18:13     ` Sergey Organov
2022-11-27  9:37 ` [PATCH 2/5] diff-merges: implement log.diffMerges-m-imply-p config Sergey Organov
2022-11-27  9:37 ` [PATCH 3/5] diff-merges: implement log.diffMergesForce config Sergey Organov
2022-11-28  2:35   ` Junio C Hamano
2022-11-28 14:44     ` Sergey Organov
2022-11-29 15:30       ` Junio C Hamano
2022-11-29 17:59         ` Ævar Arnfjörð Bjarmason
2022-11-30 13:01           ` Sergey Organov
2022-11-30 13:28           ` Junio C Hamano
2022-11-29 18:48       ` Jeff King
2022-11-30 13:02         ` Sergey Organov
2022-11-29  5:10   ` Elijah Newren
2022-11-30 12:58     ` Sergey Organov
2022-11-27  9:37 ` [PATCH 4/5] diff-merges: support list of values for --diff-merges Sergey Organov
2022-11-27  9:37 ` [PATCH 5/5] diff-merges: issue warning on lone '-m' option Sergey Organov
2022-11-28  7:51 ` [PATCH 0/5] diff-merges: more features Junio C Hamano
2022-11-28 14:42   ` Sergey Organov
2022-11-29  4:50 ` Elijah Newren [this message]
2022-11-30 13:16   ` Sergey Organov
2022-12-01  2:21     ` Elijah Newren
2022-12-01  9:36       ` Sergey Organov
2022-12-07 23:55 ` Glen Choo
2022-12-08 14:29   ` Sergey Organov
2022-12-08 23:05     ` Glen Choo
2022-12-10 20:45       ` Sergey Organov
2022-12-08 23:06     ` Glen Choo
2022-12-08 16:18   ` Sergey Organov
2022-12-17 13:29   ` [PATCH v1 0/5] diff-merges: more features to fix '-m' Sergey Organov
2022-12-17 13:29     ` [PATCH v1 1/5] diff-merges: implement [no-]hide option and log.diffMergesHide config Sergey Organov
2022-12-17 13:29     ` [PATCH v1 2/5] diff-merges: implement log.diffMerges-m-imply-p config Sergey Organov
2022-12-17 13:29     ` [PATCH v1 3/5] diff-merges: support list of values for --diff-merges Sergey Organov
2022-12-17 13:29     ` [PATCH v1 4/5] diff-merges: issue warning on lone '-m' option Sergey Organov
2022-12-17 13:29     ` [PATCH v1 5/5] diff-merges: improve --diff-merges documentation Sergey Organov
2022-12-18  3:10     ` [PATCH v1 0/5] diff-merges: more features to fix '-m' Junio C Hamano
2022-12-19 14:22       ` Sergey Organov
2022-12-19 14:29       ` Sergey Organov

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='CABPp-BHaPpQdO-uBT6ENHAM1Y-c=SBxktH-S_BTtxJvfd1qSpw@mail.gmail.com' \
    --to=newren@gmail.com \
    --cc=alexhenrie24@gmail.com \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=gl041188@gmail.com \
    --cc=jrnieder@gmail.com \
    --cc=peff@peff.net \
    --cc=philipoakley@iee.email \
    --cc=sorganov@gmail.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).