All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, Taylor Blau <me@ttaylorr.com>,
	Phillip Wood <phillip.wood123@gmail.com>
Subject: Re: [PATCH v3] rebase: clarify conditionals in todo_list_to_strbuf()
Date: Wed, 9 Aug 2023 18:13:21 +0200	[thread overview]
Message-ID: <ZNO7IVphPf8KOC3Q@ugly> (raw)
In-Reply-To: <xmqqv8dqd2bh.fsf@gitster.g>

On Mon, Aug 07, 2023 at 01:28:50PM -0700, Junio C Hamano wrote:
>Oswald Buddenhagen <oswald.buddenhagen@gmx.de> writes:
>
>>  			if (item->command == TODO_FIXUP) {
>>  				if (item->flags & TODO_EDIT_FIXUP_MSG)
>>  					strbuf_addstr(buf, " -c");
>> -				else if (item->flags & TODO_REPLACE_FIXUP_MSG) {
>> +				else if (item->flags & TODO_REPLACE_FIXUP_MSG)
>>  					strbuf_addstr(buf, " -C");
>> -				}
>> -			}
>> -
>> -			if (item->command == TODO_MERGE) {
>> +			} else if (item->command == TODO_MERGE) {
>>  				if (item->flags & TODO_EDIT_MERGE_MSG)
>>  					strbuf_addstr(buf, " -c");
>>  				else
>
>This patch as it stands is a strict Meh at least to me, as we know
>item->command is not something we will mess with in the loop,
>
the "we know" is actually something the reader needs to establish in 
their mind. it's simply unnecessary cognitive load.

>so
>turning two if() into if/elseif does not add all that much value in
>readability.
>
but it adds *some* value, and i don't think it's very constructive to 
fight that. in fact, i find the whole thread rather demotivating, and 
it's ironic that felipe's response was the most reasonable one.

>Having said that.
>
>The code makes casual readers curious about other things.
>
> * Are FIXUP and MERGE the only two commands that need to be treated
>   differently here?
>
yes, and it's obvious why. i don't think that explaining it in prose 
would make the answer any more accessible.

> * Can item->commit be some other TODO_* command?
>
the fact that it's an else-if implies that much. the definite yes is 
clear from the bigger context.

>What is the reason why they can be no-op?
>
i have no clue what you're referring to.

> * When one wants to invent a new kind of TODO_* command, what is
>   the right way to deal with it in this if/else cascade?
>
i think that someone who actually wants to modify the code can be 
expected to come up with an answer themselves, as this is a much rarer 
occurrence than just reading the code.

>And that leads me to wonder if this is better rewritten with
>
>	switch (item->command) {
>
as the commit message was meant to imply, my answer to that is no.

regards

  reply	other threads:[~2023-08-09 16:13 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-23 16:22 [PATCH] rebase: clarify conditionals in todo_list_to_strbuf() Oswald Buddenhagen
2023-03-23 20:32 ` Taylor Blau
2023-03-24  8:59   ` Oswald Buddenhagen
2023-03-24 14:39   ` Phillip Wood
2023-04-28 12:56 ` [PATCH v2] " Oswald Buddenhagen
2023-05-02 18:51   ` Felipe Contreras
2023-08-07 17:09   ` [PATCH v3] " Oswald Buddenhagen
2023-08-07 20:28     ` Junio C Hamano
2023-08-09 16:13       ` Oswald Buddenhagen [this message]
2023-08-09 19:39         ` Junio C Hamano
2023-08-10 12:08           ` Oswald Buddenhagen
2023-08-10 16:03             ` Junio C Hamano
2023-08-11 10:33               ` Oswald Buddenhagen
2023-08-11 11:41                 ` Richard Kerry

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=ZNO7IVphPf8KOC3Q@ugly \
    --to=oswald.buddenhagen@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=me@ttaylorr.com \
    --cc=phillip.wood123@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.