From: Sergey Organov <sorganov@gmail.com>
To: Elijah Newren <newren@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: Wed, 30 Nov 2022 16:16:02 +0300 [thread overview]
Message-ID: <87lenstwfh.fsf@osv.gnss.ru> (raw)
In-Reply-To: <CABPp-BHaPpQdO-uBT6ENHAM1Y-c=SBxktH-S_BTtxJvfd1qSpw@mail.gmail.com> (Elijah Newren's message of "Mon, 28 Nov 2022 20:50:45 -0800")
Elijah Newren <newren@gmail.com> writes:
> 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?
Yes, it's a precedent indeed, but I don't see any actual problem here.
Unlike git silently dropping changes on rebase, this can cause no
damage. I think I can emphasize that we now have "formats" and "flags"
in the documentation, where "formats" are mutually exclusive (the latest
specified wins), while "flags" are cumulative.
>
>> 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?
Completeness is essential as I want '--diff-merges' to provide all the
needed capabilities, and one of them was actually missing, that is there
in the '-m' semantics, exactly as I said in the descriptions.
>
>> 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)?
As I said in my answer to your other mail, '-m' is already configurable,
so it is not needed to be included.
None of --diff-merges= options are affected by diffMergesForce, only 3
specific options from the documentation.
>
> 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...
Yeah, thanks, I got your suggestion you put in another mail.
>
>> 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.
Yes, they can. For now it's useful only for 'hide', but we might add
more flags in the future. It's also harmless, so I don't see it as a
serious issue.
Thanks,
-- Sergey Organov
next prev parent reply other threads:[~2022-11-30 13:16 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
2022-11-30 13:16 ` Sergey Organov [this message]
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=87lenstwfh.fsf@osv.gnss.ru \
--to=sorganov@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=newren@gmail.com \
--cc=peff@peff.net \
--cc=philipoakley@iee.email \
/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).