From: Junio C Hamano <gitster@pobox.com>
To: Derrick Stolee <stolee@gmail.com>
Cc: "SZEDER Gábor" <szeder.dev@gmail.com>, git@vger.kernel.org
Subject: Re: [PATCH 4/4] line-log: simplify condition checking for merge commits
Date: Mon, 25 Aug 2025 14:57:17 -0700 [thread overview]
Message-ID: <xmqqqzwznjya.fsf@gitster.g> (raw)
In-Reply-To: <f98f3db4-cd36-4a24-903f-7aebf6af3d51@gmail.com> (Derrick Stolee's message of "Mon, 25 Aug 2025 17:43:10 -0400")
Derrick Stolee <stolee@gmail.com> writes:
> ... but the negation and OR condition made me need to pause and
> think about it, while the positive of "does it have a parent and
> a second parent?" was something that flowed naturally when I read
> it.
Yeah, that I 100% agree with. If it were
if (!(c->parent && c->parent->next))
handle_ordinary_commit();
else
handle_merge_commit();
that would have been very easy to grok. I do not have a strong
preference between that and
if (c->parent && c->parent->next)
handle_merge_commit();
else
handle_ordinary_commit();
myself, but I always felt that handling ordinary commits was the
primary thing in this code path, which made me react to the swapping
of orders of these two calls.
> Definitely a taste thing, so I could see you wanting to skip this
> one on a pure "don't touch what's not broken" policy.
True, too, but the code that fails to be in a readable shape too
falls into the "broken" category, so in that sense I do not mind
queuing the patch, either (and indeed tonight's 'seen' will include
this step in the topic).
Thanks.
next prev parent reply other threads:[~2025-08-25 21:57 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-24 19:06 [PATCH 0/4] line-log: optimize merge commit processing SZEDER Gábor
2025-08-24 19:06 ` [PATCH 1/4] line-log: avoid unnecessary tree diffs when processing merge commits SZEDER Gábor
2025-08-25 14:13 ` Derrick Stolee
2025-08-25 15:35 ` Junio C Hamano
2025-08-28 20:27 ` SZEDER Gábor
2025-08-24 19:06 ` [PATCH 2/4] line-log: get rid of the parents array in process_ranges_merge_commit() SZEDER Gábor
2025-08-24 19:06 ` [PATCH 3/4] line-log: initialize diff queue in process_ranges_ordinary_commit() SZEDER Gábor
2025-08-24 19:06 ` [PATCH 4/4] line-log: simplify condition checking for merge commits SZEDER Gábor
2025-08-25 20:57 ` Junio C Hamano
2025-08-25 21:43 ` Derrick Stolee
2025-08-25 21:57 ` Junio C Hamano [this message]
2025-08-25 14:16 ` [PATCH 0/4] line-log: optimize merge commit processing Derrick Stolee
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=xmqqqzwznjya.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=stolee@gmail.com \
--cc=szeder.dev@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.