]> git.ipfire.org Git - thirdparty/git.git/commit
sequencer: make it clearer that commit descriptions are just comments
authorElijah Newren <newren@gmail.com>
Fri, 16 May 2025 16:26:26 +0000 (16:26 +0000)
committerJunio C Hamano <gitster@pobox.com>
Fri, 16 May 2025 19:28:27 +0000 (12:28 -0700)
commite42667241de12840ef58c0ba1c060b86c850bae0
tree28a29534bf7fa43c0389ea8d0543f03351995f89
parentcb96e1697ad6e54d11fc920c95f82977f8e438f8
sequencer: make it clearer that commit descriptions are just comments

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.
 */

Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
sequencer.c
t/t3404-rebase-interactive.sh
t/t3415-rebase-autosquash.sh
t/t3430-rebase-merges.sh
t/t5520-pull.sh
t/t7512-status-help.sh