2.6.0: Comment in rebase instruction has become too rigid

Hi,

I noticed that the format of the comment lines in a rebase instruction sheet has become stricter - it could no longer begin with spaces or tabs. The comment char ("#" for example) has to appear on the first column.

This break my little script (activated via some key binding in my $EDITOR) for adding the list of modified files under each "pick" command. The way I have it setup is something like this, given the following rebase intruction:

  pick deadbeef some commit message
  pick cafebabe another commit message

I'd hit that key in my editor that filters the pick instructions add inserts the list of the modified files in each commit so that the instruction sheet becomes like this:

  pick deadbeef some commit message
     # M path/to/foo.txt | 15 ++++----------
  pick cafebabe another commit message
     # M bar.txt | 2 +-

IIRC before git 2.6.0 this worked fine. With git 2.6.0 the rebase stops midway with warning about invalid instruction due to the now no-longer recognized indented comments.

I could work around this by changing my script so that it removes the indentation prefix so that the instruction would become like this:

  pick deadbeef some commit message
  # M path/to/foo.txt | 15 ++++----------
  pick cafebabe another commit message
  # M bar.txt | 2 +-

but this would make it harder to read because of the increased clutter between the rebase instructions and the informative "what files were changed in this commit" comment.

Looking at git-rebase--interactive.sh it seems that this is due to "git stripspace --strip-comments".

Would it be okay if the behavior is reverted to the old one - which is to recognize indented comments in the rebase instruction?

Nazri

Nazri Ramliy <ayiehere@gmail.com> writes:

Confirmed: Git 2.1.4 accepts this, 2.6 doesn't:

Warning: the command isn't recognized in the following line:
 - # pick dbafac11052a0075233bdcf0b71f54d1503aa82d test

You can fix this with 'git rebase --edit-todo'. Or you can abort the rebase with 'git rebase --abort'.

I didn't bisect, but I guess this was introduced in the series introducing this check on the todolist before starting the bisection.

Actually, I think we accepted indented comments by mistake: the semantics of comments in Git is usually that it must start at the first column (try an indented # in a commit buffer, it's not a comment). But since Git accepted it in the past, we should continue accepting it to avoid breaking the user experience.

No time to send a patch right now, but I will hopefully be able to do this within the next few days. It should be essentially a s/^ *// before calling stripspaces.

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:

Indeed:

804098bb30a5339cccb0be981a3e876245aa0ae5 is the first bad commit
commit 804098bb30a5339cccb0be981a3e876245aa0ae5
Author: Galan Rémi <remi.galan-alfonso@ensimag.grenoble-inp.fr>
Date:   Mon Jun 29 22:20:32 2015 +0200

    git rebase -i: add static check for commands and SHA-1
    
    Check before the start of the rebasing if the commands exists, and for
    the commands expecting a SHA-1, check if the SHA-1 is present and
    corresponds to a commit. In case of error, print the error, stop git
    rebase and prompt the user to fix with 'git rebase --edit-todo' or to
    abort.
    
    This allows to avoid doing half of a rebase before finding an error
    and giving back what's left of the todo list to the user and prompt
    him to fix when it might be too late for him to do so (he might have
    to abort and restart the rebase).
    
    Signed-off-by: Galan Rémi <remi.galan-alfonso@ensimag.grenoble-inp.fr>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>

:100644 100644 c26a200a6c0e7edd2b182b71af50df52179d295f dcc3401b5a8c45fd9c5ba474416eb4a6c3c9a29e M git-rebase--interactive.sh :040000 040000 3a2882c656f4a2ea3cfcba7e5afca79877c61295 522781ff8b31d55b76064d27f3d4326026721091 M t

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:

Yup, before that series, expand_todo_ids -> transfom_todo_ids ended up reading each line with "while read -r command rest" loop and the we did not honor the usual "# at the beginning line is the comment" convention, which I think was a bug. With that commit, a separate step in check_bad_cmd_and_sha1 uses a similar looking "while read" loop but forgets to take '#' into account.

I know you alluded to preprocess what is fed to stripspace, but I wonder if we can remove the misguided call to stripspace in the first place and do something like the attached instead.

 git-rebase--interactive.sh | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

Junio C Hamano <gitster@pobox.com> writes:

Nah, that would not work, as I misread the "split only at SP" manual parsing of $line.

I shouldn't be responding to the git list traffic on my vacation day, especially before my first caffeine X-<

2015-09-29 20:17 GMT+02:00 Junio C Hamano <gitster@pobox.com>:

If so, I think we should use "$comment_char"* here.