From: Sergey Organov <sorganov@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: "Jeff King" <peff@peff.net>,
"Philip Oakley" <philipoakley@iee.email>,
"Elijah Newren" <newren@gmail.com>,
"Æ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 17:42:17 +0300 [thread overview]
Message-ID: <877czfgmye.fsf@osv.gnss.ru> (raw)
In-Reply-To: <xmqqfse37c0n.fsf@gitster.g> (Junio C. Hamano's message of "Mon, 28 Nov 2022 16:51:04 +0900")
Junio C Hamano <gitster@pobox.com> writes:
> Sergey Organov <sorganov@gmail.com> writes:
>
>> 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.
>
> I do not know how this can be a good idea. For those users who set
> the configuration variables, those scripts and aliases get broken
> anyway, don't they? IOW, I am not sure how this is better than the
> "modification of '-m'" that is "a bad idea".
The history behind this is that before the patch #1 of these series
there was no way to get exact semantics of current '-m' option using new
--diff-merges option, so there was no sensible way to "fix" these
scripts/aliases. That was in fact the primary objection for the new '-m'
semantics.
Now, when one stomps on such script/alias (by explicitly enabling the
new configuration option), they can fix it by replacing '-m' with
'--diff-merges=on,hide', that, along with the last patch of these series
that produces warning when lone '-m' is detected, looks to me as a way
to eventually get rid of the legacy and surprising '-m' semantics.
> I would understand why it may be a safer and more sensible solution,
> if the proposed approach were to find an unused letter $X and to
> introduce "-$X" that is the same as "-m" but implies "-p", though.
I've in fact considered this as well, and '-d' was free for such use
last time I've checked. It was very tempting to just add '-d' that
always shows diff to first parent for everything, be it merge or not,
and call it a day, but it won't fix '-m', which inconsistent behavior
still surprises people, and besides started the whole --diff-merges
business in the first place.
>
>> 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.
>
> Not convinced it is a good idea for the same reason as above (not
> convinced it is a bad idea, either, though).
Here the intention was entirely different though. I'm using magit and it
does hard-code --cc in one place that I'd like to be able to override.
If I got this problem, I figured chances are high somebody else will get
it as well, and that's the rationale.
Then I figure everybody here has own favorite format for merge commits,
and this toy gives you exactly this: whatever option is used (once), you
get what you prefer instead, or use an option second time to enforce it.
For stable scripting, we for rather long time now have --diff-merges=c,
and --diff-merges=cc, as well as slightly more recent
--diff-merges=remerge, that are not affected by the configuration in
question.
That said, it looks useful to me, but I won't insist on the feature
should you guys object.
>
>> 4. Support list of values for --diff-merges
>>
>> This allows for shorter --diff-merges=on,hide forms.
>
> Good, probably.
Was useless before 'hide' though, as the rest of options just override
each other entirely.
Thanks,
-- Sergey Organov
next prev parent reply other threads:[~2022-11-28 14:43 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 [this message]
2022-11-29 4:50 ` Elijah Newren
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
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=877czfgmye.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.
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).