From: Sergey Organov <sorganov@gmail•com>
To: Junio C Hamano <gitster@pobox•com>
Cc: git@vger•kernel.org
Subject: Re: [PATCH 2/2] diff-merges: introduce '-d' option
Date: Tue, 26 Sep 2023 12:04:54 +0300 [thread overview]
Message-ID: <87bkdpl2yx.fsf@osv.gnss.ru> (raw)
In-Reply-To: <xmqqjzsdps0h.fsf@gitster.g> (Junio C. Hamano's message of "Mon, 25 Sep 2023 19:50:22 -0700")
Junio C Hamano <gitster@pobox•com> writes:
> Sergey Organov <sorganov@gmail•com> writes:
>
>> P.S. I also figure that maybe our divergence comes from the fact that I
>> consider merge commits to be primarily commits (introducing particular
>> set of changes, and then having reference to the source of the changes),
>> whereas you consider them primarily merges (joining two histories, and
>> then maybe some artificial changes that make merges "evil"). That's why
>> we often end up agreeing to disagree, as both these points of view seem
>> pretty valid.
>
> It rarely is the case that two opposing world views are equally
> valid, though.
Yes. In this particular case the two are not opposing though, rather
orthogonal, as they reflect the intrinsic dualism of the concept of
"merge commit". Merge commit is both a new state, and history junction,
neither of which is more or less valid or essential, and I use both
views myself, depending on situation.
An electron is both a particle and a wave, and one just uses its side
that is more convenient for explanation of the case in hand.
I promote features that I routinely need in my workflows, yet respecting
the other side of the coin as well, even though I may rarely find this
other side useful. I mean, for me, this -c/--cc (let alone -m) output is
only confusing, yet I won't be saying that it's somehow less valid than
proposed -d.
> If there were an option that forbids any comparison output from a
> single parent commit (say --ndfnm "no-diff-for-non-merge"),
> then those with "merges are the primary thing, single-parent commits
> on the merged branches are implementation details" worldview would be
> commonly using "--diff-merges=first-parent --patch --ndfnm" and (1)
> viewing only the combined effect of merging side branches without
> seeing noise from individual commits whose effects are already shown
> in these merges, and (2) traversing the side branches as well, so that
> merges from side-side branches into the side branches are viewable the
> same way as merges into the mainline.
No need to ask for a new option, as the behavior you describe is already
there, and is spelled "git log --diff-merges=first-parent"
(--diff-merges=1 for short).
> But because no such option exists and nobody asked for such an
> option during the whole lifetime of the project, I highly doubt
> that it is a valid world view with wide backing from the users.
Your concern above seems to be void, so this doesn't hold either.
As a side-note though, something like this has been asked recently, as
what you describe by --ndfnm should in fact have been what --no-patch
does, but surprisingly does not (please recall recent discussion of this
issue).
> Even if it were a valid world view with wide backing,
Apparently it is valid, otherwise there would be no need for diff to
first parent at all, let alone "git log --first-parent -p" have used it
by default.
> the combination "--diff-merges=first-parent --patch" would be less
> than ideal presentation for them (due to lack of "--ndfnm").
First, as we figured above, --ndfnm is not needed, and second, me, being
one of "them", tries hard to convince you it is the best presentation
"them" can get, while "ideal" simply never exists.
> And as I already said, it would not be useful without --first-parent
> traversal for the worldview git has supported.
Yes, you said it earlier in this thread, and as well I already explained
how it is useful without --first-parent.
> That is why I find it of dubious value to let short-and-sweet '-d'
> be squatted by less than ideal "--diff-merges=first-parent --patch"
> combination.
Hopefully I do understand your concerns, yet I believe
"--diff-merges=first-parent --patch" is way better for "-d" shortcut
than "--first-parent --patch", for the reasons I already explained
earlier in this thread.
> Shorthands are scarse resources, and we want to be careful before
> handing them out.
Yep, agreed.
I believe I carefully thought it over though, weighing all pros and
cons, and thus -d fits nicely among -c and --cc, being yet another
frequently desired format for merges, plays nice with -p as well, and is
very mnemonic, giving us convenient, user-friendly, and consistent user
interface overall.
Thanks,
-- Sergey Organov
next prev parent reply other threads:[~2023-09-26 9:05 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-09 12:54 [PATCH 0/2] diff-merges: introduce '-d' option Sergey Organov
2023-09-09 12:54 ` [PATCH 1/2] diff-merges: improve --diff-merges documentation Sergey Organov
2023-09-11 21:12 ` Junio C Hamano
2023-09-12 7:37 ` Sergey Organov
2023-09-13 0:22 ` Junio C Hamano
2023-09-18 16:20 ` Sergey Organov
2023-09-19 16:38 ` Junio C Hamano
2023-09-19 19:52 ` Sergey Organov
2023-09-09 12:54 ` [PATCH 2/2] diff-merges: introduce '-d' option Sergey Organov
2023-09-11 21:01 ` Junio C Hamano
2023-09-12 7:59 ` Sergey Organov
2023-09-14 22:17 ` Junio C Hamano
2023-09-14 23:56 ` Sergey Organov
2023-09-15 17:24 ` Junio C Hamano
2023-09-16 18:37 ` Sergey Organov
2023-09-26 2:50 ` Junio C Hamano
2023-09-26 9:04 ` Sergey Organov [this message]
2023-09-26 17:08 ` Junio C Hamano
2023-09-26 20:05 ` Sergey Organov
2023-09-20 15:02 ` [PATCH v2 0/2] " Sergey Organov
2023-09-20 15:02 ` [PATCH v2 1/2] diff-merges: improve --diff-merges documentation Sergey Organov
2023-09-20 15:02 ` [PATCH v2 2/2] diff-merges: introduce '-d' option Sergey Organov
2023-10-04 21:45 ` [PATCH v3 0/3] diff-merges: introduce '--dd' option Sergey Organov
2023-10-04 21:45 ` [PATCH v3 1/3] diff-merges: improve --diff-merges documentation Sergey Organov
2023-10-04 22:02 ` Eric Sunshine
2023-10-04 22:13 ` Sergey Organov
2023-10-05 21:11 ` Junio C Hamano
2023-10-06 17:02 ` Sergey Organov
2023-10-05 21:24 ` Junio C Hamano
2023-10-06 14:41 ` Elijah Newren
2023-10-06 17:03 ` Sergey Organov
2023-10-06 17:07 ` Sergey Organov
2023-10-06 18:01 ` Junio C Hamano
2023-10-06 18:36 ` Sergey Organov
2023-10-06 23:19 ` Junio C Hamano
2023-10-07 1:31 ` Elijah Newren
2023-10-07 1:50 ` Junio C Hamano
2023-10-07 6:49 ` Junio C Hamano
2023-10-09 17:04 ` Elijah Newren
2023-10-10 0:24 ` Junio C Hamano
2023-10-10 2:44 ` [silly] worldview documents? Junio C Hamano
2023-10-10 14:58 ` Emily Shaffer
2023-10-06 17:18 ` [PATCH v3 1/3] diff-merges: improve --diff-merges documentation Sergey Organov
2023-10-06 18:42 ` Sergey Organov
2023-10-04 21:45 ` [PATCH v3 2/3] diff-merges: introduce '--dd' option Sergey Organov
2023-10-05 21:45 ` Junio C Hamano
2023-10-06 17:05 ` Sergey Organov
2023-10-04 21:45 ` [PATCH v3 3/3] completion: complete '--dd' Sergey Organov
2023-10-05 21:45 ` Junio C Hamano
2023-10-06 18:53 ` Sergey Organov
2023-10-09 16:05 ` [PATCH v4 0/3] diff-merges: introduce '--dd' option Sergey Organov
2023-10-09 16:05 ` [PATCH v4 1/3] diff-merges: improve --diff-merges documentation Sergey Organov
2023-10-09 16:05 ` [PATCH v4 2/3] diff-merges: introduce '--dd' option Sergey Organov
2023-10-09 16:05 ` [PATCH v4 3/3] completion: complete '--dd' Sergey Organov
2023-10-09 20:02 ` [PATCH v4 0/3] diff-merges: introduce '--dd' option Junio C Hamano
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=87bkdpl2yx.fsf@osv.gnss.ru \
--to=sorganov@gmail$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=gitster@pobox$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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