Re: [PATCH] sequencer: make it clearer that commit descriptions are just comments

[Phillip Wood <phillip.wood123@gmail.com>]

Hi Elijah

On 15/05/2025 03:20, Elijah Newren via GitGitGadget wrote:
> From: Elijah Newren <newren@gmail.com>
> 
> Every once in a while, users report that editing the commit summaries
> in the todo list does not get reflected in the rebase operation,
> suggesting that users are (a) only using one-line commit messages, and
> (b) not understanding that the commit summaries are merely helpful
> comments to help them find the right hashes.
> 
> It may be difficult to correct users' poor commit messages, but we can
> at least try to make it clearer that the commit summaries are not
> directives of some sort by inserting a comment character.  Hopefully
> that leads to them looking a little further and noticing the hints at
> the bottom to use 'reword' or 'edit' directives.
> 
> Yes, this change may look funny at first since it hardcodes '#' rather
> than using comment_line_str.  However:
> 
>    * comment_line_str exists to allow disambiguation between lines in
>      a commit message and lines that are instructions to users editing
>      the commit message.  No such disambiguation is needed for these
>      comments that occur on the same line after existing directives
>    * the exact "comment" character(s) on regular pick lines used aren't
>      actually important; I could have used anything, including completely
>      random variable length text for each line and it'd work because we
>      ignore everything after 'pick' and the hash.
>    * The whole point of this change is to signal to users that they
>      should NOT be editing any part of the line after the hash (and if
>      they do so, their edits will be ignored), while the whole point of
>      comment_line_str is to allow highly flexible editing.  So making
>      it more general by using comment_line_str actually feels
>      counterproductive.
>    * The character for merge directives absolutely must be '#'; that
>      has been deeply hardcoded for a long time (see below), and will
>      break if some other comment character is used instead.  In a
>      desire to have pick and merge directives be similar, I use the
>      same comment character for both.
>    * Perhaps merge directives could be fixed to not be inflexible about
>      the comment character used, if someone feels highly motivated, but
>      I think that should be done in a separate follow-on patch.
> 
> Here are (some of?) the locations where '#' has already been hardcoded
> for a long time for merges:
> 
>    1) In check_label_or_ref_arg():
> 	case TODO_LABEL:
> 		/*
> 		 * '#' is not a valid label as the merge command uses it to
> 		 * separate merge parents from the commit subject.
> 		 */
> 
>    2) In do_merge():
> 
> 	/*
> 	 * For octopus merges, the arg starts with the list of revisions to be
> 	 * merged. The list is optionally followed by '#' and the oneline.
> 	 */
> 	merge_arg_len = oneline_offset = arg_len;
> 	for (p = arg; p - arg < arg_len; p += strspn(p, " \t\n")) {
> 		if (!*p)
> 			break;
> 		if (*p == '#' && (!p[1] || isspace(p[1]))) {
> 
>    3) In label_oid():
> 
> 		if ((buf->len == the_hash_algo->hexsz &&
> 		     !get_oid_hex(label, &dummy)) ||
> 		    (buf->len == 1 && *label == '#') ||
> 		    hashmap_get_from_hash(&state->labels,
> 					  strihash(label), label)) {
> 			/*
> 			 * If the label already exists, or if the label is a
> 			 * valid full OID, or the label is a '#' (which we use
> 			 * as a separator between merge heads and oneline), we
> 			 * append a dash and a number to make it unique.
> 			 */

Thanks for the comprehensive commit message. I think this change is a 
very good idea. The code changes all look good to me. I've left one 
comment on the tests below though I should admit that I could feel my 
eyes glazing over by the time I got to the end of all the test changes. 
The test changes are pretty much all mechanical though so I'm reasonably 
confidant that the tests would fail if there was something wrong with 
the conversion.

> diff --git a/t/t5520-pull.sh b/t/t5520-pull.sh
> index 47534f1062d..52a5e4c016b 100755
> --- a/t/t5520-pull.sh
> +++ b/t/t5520-pull.sh
> @@ -813,7 +813,7 @@ test_expect_success 'git pull --rebase does not reapply old patches' '
>   		cd dst &&
>   		test_must_fail git pull --rebase &&
>   		cat .git/rebase-merge/done .git/rebase-merge/git-rebase-todo >work &&
> -		grep -v -e \# -e ^$ work >patches &&
> +		sed -e s/#.*// work | grep -v ^$ >patches &&

I think we could just use 'sed -n "!/^#/p work >patches &&" here

Thanks

Phillip