Git development
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Phillip Wood <phillip.wood123@gmail.com>
Cc: git@vger.kernel.org,  Elijah Newren <newren@gmail.com>,
	 Patrick Steinhardt <ps@pks.im>
Subject: Re: [PATCH v3 1/2] sequencer: factor out parsing of todo commands
Date: Mon, 22 Jun 2026 10:00:24 -0700	[thread overview]
Message-ID: <xmqqpl1i1pef.fsf@gitster.g> (raw)
In-Reply-To: <d27dddff93144f7b6d7fc89719bdf53b6856c9fc.1782117361.git.phillip.wood@dunelm.org.uk> (Phillip Wood's message of "Mon, 22 Jun 2026 09:36:03 +0100")

Phillip Wood <phillip.wood123@gmail.com> writes:

> From: Phillip Wood <phillip.wood@dunelm.org.uk>
>
> Move the code that parses todo commands into a separate function so
> that it can be shared with "git status" in the next commit. As we
> know the input is NUL terminated we do not pass a pointer to the end
> of the line and instead test for a blank line by looking for NUL, CR
> LF, or LF. We use starts_with() instead of starts_with_mem() for the
> same reason. This results in slightly different behavior when there
> a CR at the start of the line that is not followed by LF. Previously
> such a line was treated as a comment rather than an invalid line.

Meaning that the input validation is tighter than before?  I think
it is fine in this case, as I do not see a reason why anybody wants
to use a lone CR as comment introducer.

> +bool sequencer_parse_todo_command(const char **p, enum todo_command *cmd)
> +{
> +	const char *s = *p;
> +
> +	for (int i = 0; i < TODO_COMMENT; i++)
> +		if (is_command(i, p)) {
> +			*cmd = i;
> +			return true;
> +		}
> +
> +	if (starts_with(s, comment_line_str)) {
> +		*cmd = TODO_COMMENT;
> +		return true;
> +	} else if (s[0] == '\n' || (s[0] == '\r' && s[1] == '\n') || !s[0]) {
> +		*cmd = TODO_COMMENT;
> +		return true;
> +	}
> +
> +	return false;
>  }

I notice that the order of noticing concrete comments and comment
lines are swapped relative to the original.  There is no inherently
"natural" order between them, so the change is perfectly OK.  I just
got confused slightly while reading it until I realized that is what
you did.

>  static int check_label_or_ref_arg(enum todo_command command, const char *arg)
> @@ -2716,29 +2737,23 @@ static int parse_insn_line(struct repository *r, struct replay_opts *opts,
>  {
>  	struct object_id commit_oid;
>  	char *end_of_object_name;
> -	int i, saved, status, padding;
> +	int saved, status, padding;
>  
>  	item->flags = 0;
>  
>  	/* left-trim */
>  	bol += strspn(bol, " \t");
>  
> -	if (bol == eol || *bol == '\r' || starts_with_mem(bol, eol - bol, comment_line_str)) {
> -		item->command = TODO_COMMENT;
> -		item->commit = NULL;
> -		item->arg_offset = bol - buf;
> -		item->arg_len = eol - bol;
> -		return 0;
> -	}
> -
> -	for (i = 0; i < TODO_COMMENT; i++)
> -		if (is_command(i, &bol)) {
> -			item->command = i;
> -			break;
> -		}
> -	if (i >= TODO_COMMENT)
> +	if (!sequencer_parse_todo_command(&bol, &item->command))
>  		return error(_("invalid command '%.*s'"),
>  			     (int)strcspn(bol, " \t\r\n"), bol);
> +
> +	if (item->command == TODO_COMMENT) {
> +		item->commit = NULL;
> +		item->arg_offset = bol - buf;
> +		item->arg_len = eol - bol;
> +		return 0;
> +	}

And the extra stuff that are only relevant to a comment line is
naturally processed by the caller.  OK.

Thanks.  Looking good so far.

  reply	other threads:[~2026-06-22 17:00 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-20 15:04 [PATCH 0/2] status: improve rebase todo list parsing Phillip Wood
2026-04-20 15:04 ` [PATCH 1/2] sequencer: factor out parsing of todo commands Phillip Wood
2026-04-22  0:32   ` Elijah Newren
2026-04-20 15:04 ` [PATCH 2/2] status: improve rebase todo list parsing Phillip Wood
2026-04-20 16:38   ` Tian Yuchen
2026-04-21 16:03     ` Phillip Wood
2026-04-22  0:32   ` Elijah Newren
2026-04-22 13:28     ` Patrick Steinhardt
2026-04-22 14:14       ` Phillip Wood
2026-04-22 14:15     ` Phillip Wood
2026-05-01 15:16 ` [PATCH v2 0/2] " Phillip Wood
2026-05-01 15:16   ` [PATCH v2 1/2] sequencer: factor out parsing of todo commands Phillip Wood
2026-05-01 15:16   ` [PATCH v2 2/2] status: improve rebase todo list parsing Phillip Wood
2026-05-31  0:46     ` Junio C Hamano
2026-06-01 15:20       ` Phillip Wood
2026-06-11 16:08         ` Junio C Hamano
2026-06-22  8:36           ` Phillip Wood
2026-05-01 18:19   ` [PATCH v2 0/2] " Phillip Wood
2026-06-22  8:36 ` [PATCH v3 " Phillip Wood
2026-06-22  8:36   ` [PATCH v3 1/2] sequencer: factor out parsing of todo commands Phillip Wood
2026-06-22 17:00     ` Junio C Hamano [this message]
2026-06-22  8:36   ` [PATCH v3 2/2] status: improve rebase todo list parsing Phillip Wood
2026-06-22 17:26     ` 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=xmqqpl1i1pef.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=newren@gmail.com \
    --cc=phillip.wood123@gmail.com \
    --cc=ps@pks.im \
    /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