git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] rebase -i: check labels and refs when parsing todo list

From
PWPhillip Wood <phillip.wood123@gmail.com>
Date
Feb 20, 2023, 09:24 UTC
Message-ID
<5a2a62cc-134c-adb0-7cab-c08c16c2dfdf@dunelm.org.uk>
In-Reply-To
<0578e154-4c28-ffd9-03fc-5f9f5939cd17@github.com>
Hi Stolee
On 17/02/2023 15:32, Derrick Stolee wrote:
Show 35 quoted lines
> On 2/17/2023 9:37 AM, Phillip Wood via GitGitGadget wrote:
>> From: Phillip Wood <phillip.wood@dunelm.org.uk>
>>
>> Check that the argument to the "label" and "update-ref" commands is a
>> valid refname when the todo list is parsed rather than waiting until the
>> command is executed. This means that the user can deal with any errors
>> at the beginning of the rebase rather than having it stop halfway
>> through due to a typo in a label name.
> 
> Thanks for thinking about this user experience. This is a good
> improvement to the user interaction.
> 
>> The "update-ref" command is
>> changed to reject single level refs as it is all to easy to type
>> "update-ref branch" which is incorrect rather than "update-ref
>> refs/heads/branch"
> 
> I think it's good to start by adding the restriction in this
> check, but we could revisit this requirement in the future to
> see if it is worth allowing the user to drop "refs/heads/" and
> let it be implied. It just adds some complexity to the parsing,
> so this patch adds helpful scaffolding (in checks and tests)
> such that we could do that later in a safer way.
> 
>> +static int check_label_or_ref_arg(enum todo_command command, const char *arg)
>> +{
>> +	int allow_onelevel =
>> +		command == TODO_LABEL ? REFNAME_ALLOW_ONELEVEL : 0;
>> +
>> +	if ((command == TODO_LABEL && !strcmp(arg, "#")) ||
> 
> Interesting that "#" means something special for the label, and
> it's not limited to just the start of the label name, but must
> be the entire string. Is this not something that
> check_refname_format() would catch?

"#" is a valid refname, but the merge command uses it to separate the merge parents from the commit summary so it cannot be used as a label. It is rejected at the start of do_label() (arguably that check could be removed with this series but I'm tempted to leave it alone)

Show 8 quoted lines
> Is the motivation that users
> might add what they think is a comment, such as:
> 
>    label # make a label here
> 
> but oddly, this doesn't include something strange like
> 
>    label #make a label here

I've actually got some patches based on this that add support for comments like this, but they are not the reason that "#" is forbidden as a label here.

Show 42 quoted lines
>> +	    check_refname_format(arg, allow_onelevel)) {
>> +		if (command == TODO_LABEL)
>> +			error(_("'%s' is not a valid label"), arg);
> 
> If we have any kind of error and we are in TODO_LABEL, then
> we can use a label message. Good.
> 
>> +		else if (check_refname_format(arg, REFNAME_ALLOW_ONELEVEL))
>> +			error(_("'%s' is not a valid refname"), arg);
>> +		else
>> +			error(_("update-ref requires a fully qualified refname e.g. refs/heads/%s"),
>> +			      arg);
> 
> This took me a little while to grok, but I think I have it
> now: when in the update-ref mode, it could fail because of a
> one-level ref (the else case) or it could fail because the
> ref name uses forbidden characters (the else if case).
> 
> This nesting of conditions seems a bit fragile if we were to
> add a new todo_command to check here. Perhaps reorganize it
> to switch on the command?
> 
> 	switch (command) {
> 	case TODO_LABEL:
> 		if (!strcmp(arg, "#") ||
> 		    check_refname_format(arg, REFNAME_ALLOW_ONELEVEL))
> 			return error(_("'%s' is not a valid label", arg);
> 		break;
> 
> 	case TODO_UPDATE_REF:
> 		if (check_refname_format(arg, REFNAME_ALLOW_ONELEVEL))
> 			return error(_("'%s' is not a valid refname"), arg);
> 		else if (check_refname_format(arg, 0))
> 			return error(_("update-ref reqruies a fully qualified refname (e.g. refs/heads/%s)",
> 				     arg);
> 		break;
> 
> 	default:
> 		BUG("unexpected todo_command");
> 	}
> 
> 	return 0;
That's definitely clearer, thanks for the suggestion
Show 31 quoted lines
>> @@ -2523,8 +2543,23 @@ static int parse_insn_line(struct repository *r, struct todo_item *item,
>>   		return error(_("missing arguments for %s"),
>>   			     command_to_string(item->command));
>>   
>> -	if (item->command == TODO_EXEC || item->command == TODO_LABEL ||
>> +	if (item->command == TODO_LABEL ||
>>   	    item->command == TODO_RESET || item->command == TODO_UPDATE_REF) {
>> +		int ret = 0;
>> +
>> +		item->commit = NULL;
>> +		item->arg_offset = bol - buf;
>> +		item->arg_len = (int)(eol - bol);
>> +		if (item->command != TODO_RESET) {
>> +			saved = *eol;
>> +			*eol = '\0';
>> +			ret = check_label_or_ref_arg(item->command, bol);
>> +			*eol = saved;
>> +		}
>> +		return ret;
>> +	}
>> +
>> +	if (item->command == TODO_EXEC) {
>>   		item->commit = NULL;
>>   		item->arg_offset = bol - buf;
>>   		item->arg_len = (int)(eol - bol);
> 
> (What's missing from this context is "return 0;")
> 
> Is there an important reason why you separated TODO_EXEC and
> its identical item->arg_(offset|len) parsing into its own
> block?

In a word no! This patch was pulled out from the series I mentioned above that adds support for comments. There it makes sense to treat exec commands separately as they cannot have comments but you're right that there is no need to do that in this patch.

Show 24 quoted lines
> It seems like we could modify your change to look like
> this:
> 
> 
> 	if (item->command == TODO_EXEC || item->command == TODO_LABEL ||
>    	    item->command == TODO_RESET || item->command == TODO_UPDATE_REF) {
> 		int ret = 0;
> 
> 		item->commit = NULL;
> 		item->arg_offset = bol - buf;
> 		item->arg_len = (int)(eol - bol);
> 		if (item->command == TODO_RESET ||
> 		    item->command == TODO_UPDATE_REF) {
> 			saved = *eol;
> 			*eol = '\0';
> 			ret = check_label_or_ref_arg(item->command, bol);
> 			*eol = saved;
> 		}
> 		return ret;
> 	}
> 
> and the diff will have fewer new lines as well as fewer
> duplicate lines in the post-image. Am I missing something
> about TODO_EXEC being special?
I'll update as you suggest
Show 17 quoted lines
>> diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
>> index 462cefd25df..2cf2d2b8a24 100755
>> --- a/t/t3404-rebase-interactive.sh
>> +++ b/t/t3404-rebase-interactive.sh
>> @@ -2120,7 +2120,30 @@ test_expect_success '--update-refs: check failed ref update' '
>>   	tail -n 6 err >err.last &&
>>   	sed -e "s/Rebasing.*Successfully/Successfully/g" -e "s/^\t//g" \
>>   		<err.last >err.trimmed &&
>> -	test_cmp expect err.trimmed
>> +	test_cmp expect err.trimmed &&
>> +	git rebase --abort
>> +'
> 
> Perhaps this `git rebase --abort` should be part of a
> `test_when_finished test_may_fail git rebase --abort` at
> the start of the test so that your new test can succeed
> even if an earlier test step caused the test to fail.
That's a good idea (and for the next test as well)
Thanks for you're thoughtful comments and suggestions
Best Wishes
Phillip
Show 27 quoted lines
>> +test_expect_success 'bad labels and refs rejected when parsing todo list' '
>> +	cat >todo <<-\EOF &&
>> +	exec >execed
>> +	label #
>> +	label :invalid
>> +	update-ref :bad
>> +	update-ref topic
>> +	EOF
>> +	rm -f execed &&
>> +	(
>> +		set_replace_editor todo &&
>> +		test_must_fail git rebase -i HEAD 2>err
>> +	) &&
>> +	grep "'\''#'\'' is not a valid label" err &&
>> +	grep "'\'':invalid'\'' is not a valid label" err &&
>> +	grep "'\'':bad'\'' is not a valid refname" err &&
>> +	grep "update-ref requires a fully qualified refname e.g. refs/heads/topic" \
>> +		err &&
>> +	test_path_is_missing execed &&
>> +	git rebase --abort
>>   '
> 
> Again, the `git rebase --abort` seems like protection for
> future tests, so a test_when_finished would help.
> 
> Thanks,
> -Stolee
Previous: Derrick StoleeNext: Phillip Wood
Message 3 of 10 in “rebase -i: check labels and refs when parsing todo list”
  1. rebase -i: check labels and refs when parsing todo listPhillip Wood via GitGitGadget, Feb 17, 2023
  2. Derrick StoleeFeb 17, 2023
  3. Phillip WoodFeb 20, 2023
  4. Phillip WoodFeb 20, 2023
  5. rebase -i: check labels and refs when parsing todo listPhillip Wood via GitGitGadget, Feb 20, 2023
  6. Derrick StoleeFeb 21, 2023
  7. Phillip WoodFeb 21, 2023
  8. Junio C HamanoFeb 21, 2023
  9. rebase -i: check labels and refs when parsing todo listPhillip Wood via GitGitGadget, Feb 21, 2023
  10. Derrick StoleeFeb 21, 2023

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.