2.6.0: Comment in rebase instruction has become too rigid

[Nazri Ramliy]

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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: 2.6.0: Comment in rebase instruction has become too rigid

[Matthieu Moy]

Nazri Ramliy  writes:

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

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
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: 2.6.0: Comment in rebase instruction has become too rigid

[Matthieu Moy]

Matthieu Moy  writes:

> Nazri Ramliy  writes:
>
>> 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.
>
> 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.

Indeed:

804098bb30a5339cccb0be981a3e876245aa0ae5 is the first bad commit
commit 804098bb30a5339cccb0be981a3e876245aa0ae5
Author: Galan Rémi 
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 
Signed-off-by: Junio C Hamano 

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

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: 2.6.0: Comment in rebase instruction has become too rigid

[Junio C Hamano]

Matthieu Moy  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.
>
> Indeed:
>
> 804098bb30a5339cccb0be981a3e876245aa0ae5 is the first bad commit

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(-)

diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index f01637b..a64f77a 100644
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -886,7 +886,6 @@ check_commit_sha () {
 # from the todolist in stdin
 check_bad_cmd_and_sha () {
retval=0
-   git stripspace --strip-comments |
(
while read -r line
do
@@ -896,7 +895,7 @@ check_bad_cmd_and_sha () {
sha1=$2
 
case $command in
-   ''|noop|x|"exec")
+   '#'*|''|noop|x|"exec")
# Doesn't expect a SHA-1
;;
pick|p|drop|d|reword|r|edit|e|squash|s|fixup|f)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: 2.6.0: Comment in rebase instruction has become too rigid

[Junio C Hamano]

Junio C Hamano  writes:

> 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(-)
>
> diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
> index f01637b..a64f77a 100644
> --- a/git-rebase--interactive.sh
> +++ b/git-rebase--interactive.sh
> @@ -886,7 +886,6 @@ check_commit_sha () {
>  # from the todolist in stdin
>  check_bad_cmd_and_sha () {
>   retval=0
> - git stripspace --strip-comments |
>   (
>   while read -r line
>   do
> @@ -896,7 +895,7 @@ check_bad_cmd_and_sha () {
>   sha1=$2
>  
>   case $command in
> - ''|noop|x|"exec")
> + '#'*|''|noop|x|"exec")
>   # Doesn't expect a SHA-1
>   ;;
>   pick|p|drop|d|reword|r|edit|e|squash|s|fixup|f)

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-<
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: 2.6.0: Comment in rebase instruction has become too rigid

[Ralf Thielow]

2015-09-29 20:17 GMT+02:00 Junio C Hamano :
> Matthieu Moy  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.
>>
>> Indeed:
>>
>> 804098bb30a5339cccb0be981a3e876245aa0ae5 is the first bad commit
>
> 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(-)
>
> diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
> index f01637b..a64f77a 100644
> --- a/git-rebase--interactive.sh
> +++ b/git-rebase--interactive.sh
> @@ -886,7 +886,6 @@ check_commit_sha () {
>  # from the todolist in stdin
>  check_bad_cmd_and_sha () {
> retval=0
> -   git stripspace --strip-comments |
> (
> while read -r line
> do
> @@ -896,7 +895,7 @@ check_bad_cmd_and_sha () {
> sha1=$2
>
> case $command in
> -   ''|noop|x|"exec")
> +   '#'*|''|noop|x|"exec")

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

> # Doesn't expect a SHA-1
> ;;
> pick|p|drop|d|reword|r|edit|e|squash|s|fixup|f)
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html