Rebasing with submodule change causes red herring with --continue

Rebasing with submodule change causes red herring with --continue

[Robert Dailey]

I have a branch that contains a commit with a single change: A
submodule pointing to a new SHA1.

When I rebase this branch onto the tip of its parent branch AND that
parent branch had modified that same submodule, the rebase stops at
the commit on my branch that modified the submodule and asks me if I
want to keep REMOTE or LOCAL. I say LOCAL and notice immediately that
the submodule is not staged (normally it would be).

I do:

$ git add my-submodule

Then I do:

$ git rebase --continue

At this point, it fails asking me if I forgot to stage changes and
recommends doing --skip. This is normally what you would see if the
staging area was completely empty, however it isn't, since I see the
submodule is in there.

Is this a bug or am I missing a fundamental here? I'm using Git 2.1.0
on Windows through MSYS. I'll provide more concrete examples if my
summary of the issue doesn't "ring any bells".

Re: Rebasing with submodule change causes red herring with --continue

[John Keeping]

On Fri, Apr 10, 2015 at 11:30:20AM -0500, Robert Dailey wrote:
> I have a branch that contains a commit with a single change: A
> submodule pointing to a new SHA1.
> 
> When I rebase this branch onto the tip of its parent branch AND that
> parent branch had modified that same submodule, the rebase stops at
> the commit on my branch that modified the submodule and asks me if I
> want to keep REMOTE or LOCAL. I say LOCAL and notice immediately that
> the submodule is not staged (normally it would be).
> 
> I do:
> 
> $ git add my-submodule
> 
> Then I do:
> 
> $ git rebase --continue
> 
> At this point, it fails asking me if I forgot to stage changes and
> recommends doing --skip. This is normally what you would see if the
> staging area was completely empty, however it isn't, since I see the
> submodule is in there.
> 
> Is this a bug or am I missing a fundamental here? I'm using Git 2.1.0
> on Windows through MSYS. I'll provide more concrete examples if my
> summary of the issue doesn't "ring any bells".

I hit something similar in the past, but it was fixed with commit
a6754cd (rebase -i continue: don't skip commits that only change
submodules, 2012-04-07) so I think you must be hitting a slightly
different problem, although the tests added in that commit look like
they do test the scenario you describe (specifically 'rebase -i continue
with only submodule staged').

Re: Rebasing with submodule change causes red herring with --continue

[Robert Dailey]

On Fri, Apr 10, 2015 at 11:44 AM, John Keeping <john@keeping.me.uk> wrote:
> On Fri, Apr 10, 2015 at 11:30:20AM -0500, Robert Dailey wrote:
>> I have a branch that contains a commit with a single change: A
>> submodule pointing to a new SHA1.
>>
>> When I rebase this branch onto the tip of its parent branch AND that
>> parent branch had modified that same submodule, the rebase stops at
>> the commit on my branch that modified the submodule and asks me if I
>> want to keep REMOTE or LOCAL. I say LOCAL and notice immediately that
>> the submodule is not staged (normally it would be).
>>
>> I do:
>>
>> $ git add my-submodule
>>
>> Then I do:
>>
>> $ git rebase --continue
>>
>> At this point, it fails asking me if I forgot to stage changes and
>> recommends doing --skip. This is normally what you would see if the
>> staging area was completely empty, however it isn't, since I see the
>> submodule is in there.
>>
>> Is this a bug or am I missing a fundamental here? I'm using Git 2.1.0
>> on Windows through MSYS. I'll provide more concrete examples if my
>> summary of the issue doesn't "ring any bells".
>
> I hit something similar in the past, but it was fixed with commit
> a6754cd (rebase -i continue: don't skip commits that only change
> submodules, 2012-04-07) so I think you must be hitting a slightly
> different problem, although the tests added in that commit look like
> they do test the scenario you describe (specifically 'rebase -i continue
> with only submodule staged').

I am still running into this issue on git 2.3.5 on Windows. Logs
below. One interesting thing to note in the git trace output is that
it is specifying --ignore-submodules option to `git diff-files` during
the rebase continue. Is this due to a configuration option? It seems
like git should not be ignoring submodules when continuing a rebase
(this should only affect direct calls to diff)


|-- Robert@M5536:/e/code/frontend (timeline-ids-develop|REBASE 3/3) --|
$ git status
rebase in progress; onto bb05e7c
You are currently rebasing branch 'timeline-ids-develop' on 'bb05e7c'.
  (all conflicts fixed: run "git rebase --continue")

Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

        modified:   Core

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        modified:   Core (new commits)

Untracked files:
  (use "git add <file>..." to include in what will be committed)

        Tools/FontTool/


|-- Robert@M5536:/e/code/frontend (timeline-ids-develop|REBASE 3/3) --|
$ GIT_TRACE=1 git rebase --continue
19:15:33.569945 git.c:557               trace: exec: 'git-rebase' '--continue'
19:15:33.569945 run-command.c:351       trace: run_command:
'git-rebase' '--continue'
19:15:33.775097 git.c:348               trace: built-in: git
'rev-parse' '--parseopt' '--stuck-long' '--' '--continue'
19:15:33.931190 git.c:348               trace: built-in: git
'rev-parse' '--git-dir'
19:15:34.007242 git.c:348               trace: built-in: git
'rev-parse' '--is-bare-repository'
19:15:34.059280 git.c:348               trace: built-in: git
'rev-parse' '--show-toplevel'
19:15:34.148343 git.c:348               trace: built-in: git 'config'
'--bool' 'rebase.stat'
19:15:34.227399 git.c:348               trace: built-in: git 'config'
'--bool' 'rebase.autostash'
19:15:34.280437 git.c:348               trace: built-in: git 'config'
'--bool' 'rebase.autosquash'
19:15:34.335476 git.c:348               trace: built-in: git
'rev-parse' '--verify' 'HEAD'
19:15:34.389515 git.c:348               trace: built-in: git
'update-index' '--ignore-submodules' '--refresh'
19:15:34.554631 git.c:348               trace: built-in: git
'diff-files' '--quiet' '--ignore-submodules'
19:15:34.902879 git.c:557               trace: exec: 'git-am'
'--resolved' '--resolvemsg=
When you have resolved this problem, run "git rebase --continue".
If you prefer to skip this patch, run "git rebase --skip" instead.
To check out the original branch and stop rebasing, run "git rebase --abort".
'
19:15:34.902879 run-command.c:351       trace: run_command: 'git-am'
'--resolved' '--resolvemsg=
When you have resolved this problem, run "git rebase --continue".
If you prefer to skip this patch, run "git rebase --skip" instead.
To check out the original branch and stop rebasing, run "git rebase --abort".
'
19:15:35.113028 git.c:348               trace: built-in: git
'rev-parse' '--parseopt' '--stuck-long' '--' '--resolved'
'--resolvemsg=
When you have resolved this problem, run "git rebase --continue".
If you prefer to skip this patch, run "git rebase --skip" instead.
To check out the original branch and stop rebasing, run "git rebase --abort".
'
19:15:35.290155 git.c:348               trace: built-in: git
'rev-parse' '--git-dir'
19:15:35.387224 git.c:348               trace: built-in: git
'rev-parse' '--show-prefix'
19:15:35.541332 git.c:348               trace: built-in: git
'rev-parse' '--show-toplevel'
19:15:35.598374 git.c:348               trace: built-in: git 'var'
'GIT_COMMITTER_IDENT'
19:15:35.659417 git.c:348               trace: built-in: git
'rev-parse' '--verify' '-q' 'HEAD'
19:15:35.724462 git.c:348               trace: built-in: git 'config'
'--bool' '--get' 'am.messageid'
19:15:35.811524 git.c:348               trace: built-in: git 'config'
'--bool' '--get' 'am.keepcr'
19:15:36.037685 git.c:348               trace: built-in: git
'update-index' '-q' '--refresh'
19:15:37.057409 git.c:557               trace: exec:
'git-sh-i18n--envsubst' '--variables' 'Applying: $FIRSTLINE'
19:15:37.057409 run-command.c:351       trace: run_command:
'git-sh-i18n--envsubst' '--variables' 'Applying: $FIRSTLINE'
19:15:37.178495 git.c:557               trace: exec:
'git-sh-i18n--envsubst' 'Applying: $FIRSTLINE'
19:15:37.178495 run-command.c:351       trace: run_command:
'git-sh-i18n--envsubst' 'Applying: $FIRSTLINE'
Applying: TEMP: Update Core submodule
19:15:37.360624 git.c:348               trace: built-in: git
'diff-index' '--ignore-submodules' '--quiet' '--cached' 'HEAD' '--'
No changes - did you forget to use 'git add'?
If there is nothing left to stage, chances are that something else
already introduced the same changes; you might want to skip this patch.

When you have resolved this problem, run "git rebase --continue".
If you prefer to skip this patch, run "git rebase --skip" instead.
To check out the original branch and stop rebasing, run "git rebase --abort".

19:15:37.456694 git.c:348               trace: built-in: git
'rev-parse' '--verify' '-q' 'HEAD'

Re: Rebasing with submodule change causes red herring with --continue

[Robert Dailey]

On Thu, Apr 23, 2015 at 1:17 PM, Robert Dailey <rcdailey.lists@gmail.com> wrote:
> On Fri, Apr 10, 2015 at 11:44 AM, John Keeping <john@keeping.me.uk> wrote:
>> On Fri, Apr 10, 2015 at 11:30:20AM -0500, Robert Dailey wrote:
>>> I have a branch that contains a commit with a single change: A
>>> submodule pointing to a new SHA1.
>>>
>>> When I rebase this branch onto the tip of its parent branch AND that
>>> parent branch had modified that same submodule, the rebase stops at
>>> the commit on my branch that modified the submodule and asks me if I
>>> want to keep REMOTE or LOCAL. I say LOCAL and notice immediately that
>>> the submodule is not staged (normally it would be).
>>>
>>> I do:
>>>
>>> $ git add my-submodule
>>>
>>> Then I do:
>>>
>>> $ git rebase --continue
>>>
>>> At this point, it fails asking me if I forgot to stage changes and
>>> recommends doing --skip. This is normally what you would see if the
>>> staging area was completely empty, however it isn't, since I see the
>>> submodule is in there.
>>>
>>> Is this a bug or am I missing a fundamental here? I'm using Git 2.1.0
>>> on Windows through MSYS. I'll provide more concrete examples if my
>>> summary of the issue doesn't "ring any bells".
>>
>> I hit something similar in the past, but it was fixed with commit
>> a6754cd (rebase -i continue: don't skip commits that only change
>> submodules, 2012-04-07) so I think you must be hitting a slightly
>> different problem, although the tests added in that commit look like
>> they do test the scenario you describe (specifically 'rebase -i continue
>> with only submodule staged').
>
> I am still running into this issue on git 2.3.5 on Windows. Logs
> below. One interesting thing to note in the git trace output is that
> it is specifying --ignore-submodules option to `git diff-files` during
> the rebase continue. Is this due to a configuration option? It seems
> like git should not be ignoring submodules when continuing a rebase
> (this should only affect direct calls to diff)
>
>
> |-- Robert@M5536:/e/code/frontend (timeline-ids-develop|REBASE 3/3) --|
> $ git status
> rebase in progress; onto bb05e7c
> You are currently rebasing branch 'timeline-ids-develop' on 'bb05e7c'.
>   (all conflicts fixed: run "git rebase --continue")
>
> Changes to be committed:
>   (use "git reset HEAD <file>..." to unstage)
>
>         modified:   Core
>
> Changes not staged for commit:
>   (use "git add <file>..." to update what will be committed)
>   (use "git checkout -- <file>..." to discard changes in working directory)
>
>         modified:   Core (new commits)
>
> Untracked files:
>   (use "git add <file>..." to include in what will be committed)
>
>         Tools/FontTool/
>
>
> |-- Robert@M5536:/e/code/frontend (timeline-ids-develop|REBASE 3/3) --|
> $ GIT_TRACE=1 git rebase --continue
> 19:15:33.569945 git.c:557               trace: exec: 'git-rebase' '--continue'
> 19:15:33.569945 run-command.c:351       trace: run_command:
> 'git-rebase' '--continue'
> 19:15:33.775097 git.c:348               trace: built-in: git
> 'rev-parse' '--parseopt' '--stuck-long' '--' '--continue'
> 19:15:33.931190 git.c:348               trace: built-in: git
> 'rev-parse' '--git-dir'
> 19:15:34.007242 git.c:348               trace: built-in: git
> 'rev-parse' '--is-bare-repository'
> 19:15:34.059280 git.c:348               trace: built-in: git
> 'rev-parse' '--show-toplevel'
> 19:15:34.148343 git.c:348               trace: built-in: git 'config'
> '--bool' 'rebase.stat'
> 19:15:34.227399 git.c:348               trace: built-in: git 'config'
> '--bool' 'rebase.autostash'
> 19:15:34.280437 git.c:348               trace: built-in: git 'config'
> '--bool' 'rebase.autosquash'
> 19:15:34.335476 git.c:348               trace: built-in: git
> 'rev-parse' '--verify' 'HEAD'
> 19:15:34.389515 git.c:348               trace: built-in: git
> 'update-index' '--ignore-submodules' '--refresh'
> 19:15:34.554631 git.c:348               trace: built-in: git
> 'diff-files' '--quiet' '--ignore-submodules'
> 19:15:34.902879 git.c:557               trace: exec: 'git-am'
> '--resolved' '--resolvemsg=
> When you have resolved this problem, run "git rebase --continue".
> If you prefer to skip this patch, run "git rebase --skip" instead.
> To check out the original branch and stop rebasing, run "git rebase --abort".
> '
> 19:15:34.902879 run-command.c:351       trace: run_command: 'git-am'
> '--resolved' '--resolvemsg=
> When you have resolved this problem, run "git rebase --continue".
> If you prefer to skip this patch, run "git rebase --skip" instead.
> To check out the original branch and stop rebasing, run "git rebase --abort".
> '
> 19:15:35.113028 git.c:348               trace: built-in: git
> 'rev-parse' '--parseopt' '--stuck-long' '--' '--resolved'
> '--resolvemsg=
> When you have resolved this problem, run "git rebase --continue".
> If you prefer to skip this patch, run "git rebase --skip" instead.
> To check out the original branch and stop rebasing, run "git rebase --abort".
> '
> 19:15:35.290155 git.c:348               trace: built-in: git
> 'rev-parse' '--git-dir'
> 19:15:35.387224 git.c:348               trace: built-in: git
> 'rev-parse' '--show-prefix'
> 19:15:35.541332 git.c:348               trace: built-in: git
> 'rev-parse' '--show-toplevel'
> 19:15:35.598374 git.c:348               trace: built-in: git 'var'
> 'GIT_COMMITTER_IDENT'
> 19:15:35.659417 git.c:348               trace: built-in: git
> 'rev-parse' '--verify' '-q' 'HEAD'
> 19:15:35.724462 git.c:348               trace: built-in: git 'config'
> '--bool' '--get' 'am.messageid'
> 19:15:35.811524 git.c:348               trace: built-in: git 'config'
> '--bool' '--get' 'am.keepcr'
> 19:15:36.037685 git.c:348               trace: built-in: git
> 'update-index' '-q' '--refresh'
> 19:15:37.057409 git.c:557               trace: exec:
> 'git-sh-i18n--envsubst' '--variables' 'Applying: $FIRSTLINE'
> 19:15:37.057409 run-command.c:351       trace: run_command:
> 'git-sh-i18n--envsubst' '--variables' 'Applying: $FIRSTLINE'
> 19:15:37.178495 git.c:557               trace: exec:
> 'git-sh-i18n--envsubst' 'Applying: $FIRSTLINE'
> 19:15:37.178495 run-command.c:351       trace: run_command:
> 'git-sh-i18n--envsubst' 'Applying: $FIRSTLINE'
> Applying: TEMP: Update Core submodule
> 19:15:37.360624 git.c:348               trace: built-in: git
> 'diff-index' '--ignore-submodules' '--quiet' '--cached' 'HEAD' '--'
> No changes - did you forget to use 'git add'?
> If there is nothing left to stage, chances are that something else
> already introduced the same changes; you might want to skip this patch.
>
> When you have resolved this problem, run "git rebase --continue".
> If you prefer to skip this patch, run "git rebase --skip" instead.
> To check out the original branch and stop rebasing, run "git rebase --abort".
>
> 19:15:37.456694 git.c:348               trace: built-in: git
> 'rev-parse' '--verify' '-q' 'HEAD'


For reference, I found an existing mailing list discussion on this
from a few years ago:
http://git.661346.n2.nabble.com/Interactive-rebase-with-submodules-td7197519.html

Apparently a patch was proposed, i do not know if it made it in a
release of Git. But based on what I'm seeing right now, it seems that
it did not.

Re: Rebasing with submodule change causes red herring with --continue

[Jens Lehmann]

Am 23.04.2015 um 21:07 schrieb Robert Dailey:
> On Thu, Apr 23, 2015 at 1:17 PM, Robert Dailey <rcdailey.lists@gmail.com> wrote:
>> On Fri, Apr 10, 2015 at 11:44 AM, John Keeping <john@keeping.me.uk> wrote:
>>> On Fri, Apr 10, 2015 at 11:30:20AM -0500, Robert Dailey wrote:
>>>> I have a branch that contains a commit with a single change: A
>>>> submodule pointing to a new SHA1.
>>>>
>>>> When I rebase this branch onto the tip of its parent branch AND that
>>>> parent branch had modified that same submodule, the rebase stops at
>>>> the commit on my branch that modified the submodule and asks me if I
>>>> want to keep REMOTE or LOCAL. I say LOCAL and notice immediately that
>>>> the submodule is not staged (normally it would be).
>>>>
>>>> I do:
>>>>
>>>> $ git add my-submodule
>>>>
>>>> Then I do:
>>>>
>>>> $ git rebase --continue
>>>>
>>>> At this point, it fails asking me if I forgot to stage changes and
>>>> recommends doing --skip. This is normally what you would see if the
>>>> staging area was completely empty, however it isn't, since I see the
>>>> submodule is in there.
>>>>
>>>> Is this a bug or am I missing a fundamental here? I'm using Git 2.1.0
>>>> on Windows through MSYS. I'll provide more concrete examples if my
>>>> summary of the issue doesn't "ring any bells".
>>>
>>> I hit something similar in the past, but it was fixed with commit
>>> a6754cd (rebase -i continue: don't skip commits that only change
>>> submodules, 2012-04-07) so I think you must be hitting a slightly
>>> different problem, although the tests added in that commit look like
>>> they do test the scenario you describe (specifically 'rebase -i continue
>>> with only submodule staged').
>>
>> I am still running into this issue on git 2.3.5 on Windows. Logs
>> below. One interesting thing to note in the git trace output is that
>> it is specifying --ignore-submodules option to `git diff-files` during
>> the rebase continue. Is this due to a configuration option? It seems
>> like git should not be ignoring submodules when continuing a rebase
>> (this should only affect direct calls to diff)
>>
>>
>> |-- Robert@M5536:/e/code/frontend (timeline-ids-develop|REBASE 3/3) --|
>> $ git status
>> rebase in progress; onto bb05e7c
>> You are currently rebasing branch 'timeline-ids-develop' on 'bb05e7c'.
>>    (all conflicts fixed: run "git rebase --continue")
>>
>> Changes to be committed:
>>    (use "git reset HEAD <file>..." to unstage)
>>
>>          modified:   Core
>>
>> Changes not staged for commit:
>>    (use "git add <file>..." to update what will be committed)
>>    (use "git checkout -- <file>..." to discard changes in working directory)
>>
>>          modified:   Core (new commits)
>>
>> Untracked files:
>>    (use "git add <file>..." to include in what will be committed)
>>
>>          Tools/FontTool/
>>
>>
>> |-- Robert@M5536:/e/code/frontend (timeline-ids-develop|REBASE 3/3) --|
>> $ GIT_TRACE=1 git rebase --continue
>> 19:15:33.569945 git.c:557               trace: exec: 'git-rebase' '--continue'
>> 19:15:33.569945 run-command.c:351       trace: run_command:
>> 'git-rebase' '--continue'
>> 19:15:33.775097 git.c:348               trace: built-in: git
>> 'rev-parse' '--parseopt' '--stuck-long' '--' '--continue'
>> 19:15:33.931190 git.c:348               trace: built-in: git
>> 'rev-parse' '--git-dir'
>> 19:15:34.007242 git.c:348               trace: built-in: git
>> 'rev-parse' '--is-bare-repository'
>> 19:15:34.059280 git.c:348               trace: built-in: git
>> 'rev-parse' '--show-toplevel'
>> 19:15:34.148343 git.c:348               trace: built-in: git 'config'
>> '--bool' 'rebase.stat'
>> 19:15:34.227399 git.c:348               trace: built-in: git 'config'
>> '--bool' 'rebase.autostash'
>> 19:15:34.280437 git.c:348               trace: built-in: git 'config'
>> '--bool' 'rebase.autosquash'
>> 19:15:34.335476 git.c:348               trace: built-in: git
>> 'rev-parse' '--verify' 'HEAD'
>> 19:15:34.389515 git.c:348               trace: built-in: git
>> 'update-index' '--ignore-submodules' '--refresh'
>> 19:15:34.554631 git.c:348               trace: built-in: git
>> 'diff-files' '--quiet' '--ignore-submodules'
>> 19:15:34.902879 git.c:557               trace: exec: 'git-am'
>> '--resolved' '--resolvemsg=
>> When you have resolved this problem, run "git rebase --continue".
>> If you prefer to skip this patch, run "git rebase --skip" instead.
>> To check out the original branch and stop rebasing, run "git rebase --abort".
>> '
>> 19:15:34.902879 run-command.c:351       trace: run_command: 'git-am'
>> '--resolved' '--resolvemsg=
>> When you have resolved this problem, run "git rebase --continue".
>> If you prefer to skip this patch, run "git rebase --skip" instead.
>> To check out the original branch and stop rebasing, run "git rebase --abort".
>> '
>> 19:15:35.113028 git.c:348               trace: built-in: git
>> 'rev-parse' '--parseopt' '--stuck-long' '--' '--resolved'
>> '--resolvemsg=
>> When you have resolved this problem, run "git rebase --continue".
>> If you prefer to skip this patch, run "git rebase --skip" instead.
>> To check out the original branch and stop rebasing, run "git rebase --abort".
>> '
>> 19:15:35.290155 git.c:348               trace: built-in: git
>> 'rev-parse' '--git-dir'
>> 19:15:35.387224 git.c:348               trace: built-in: git
>> 'rev-parse' '--show-prefix'
>> 19:15:35.541332 git.c:348               trace: built-in: git
>> 'rev-parse' '--show-toplevel'
>> 19:15:35.598374 git.c:348               trace: built-in: git 'var'
>> 'GIT_COMMITTER_IDENT'
>> 19:15:35.659417 git.c:348               trace: built-in: git
>> 'rev-parse' '--verify' '-q' 'HEAD'
>> 19:15:35.724462 git.c:348               trace: built-in: git 'config'
>> '--bool' '--get' 'am.messageid'
>> 19:15:35.811524 git.c:348               trace: built-in: git 'config'
>> '--bool' '--get' 'am.keepcr'
>> 19:15:36.037685 git.c:348               trace: built-in: git
>> 'update-index' '-q' '--refresh'
>> 19:15:37.057409 git.c:557               trace: exec:
>> 'git-sh-i18n--envsubst' '--variables' 'Applying: $FIRSTLINE'
>> 19:15:37.057409 run-command.c:351       trace: run_command:
>> 'git-sh-i18n--envsubst' '--variables' 'Applying: $FIRSTLINE'
>> 19:15:37.178495 git.c:557               trace: exec:
>> 'git-sh-i18n--envsubst' 'Applying: $FIRSTLINE'
>> 19:15:37.178495 run-command.c:351       trace: run_command:
>> 'git-sh-i18n--envsubst' 'Applying: $FIRSTLINE'
>> Applying: TEMP: Update Core submodule
>> 19:15:37.360624 git.c:348               trace: built-in: git
>> 'diff-index' '--ignore-submodules' '--quiet' '--cached' 'HEAD' '--'
>> No changes - did you forget to use 'git add'?
>> If there is nothing left to stage, chances are that something else
>> already introduced the same changes; you might want to skip this patch.
>>
>> When you have resolved this problem, run "git rebase --continue".
>> If you prefer to skip this patch, run "git rebase --skip" instead.
>> To check out the original branch and stop rebasing, run "git rebase --abort".
>>
>> 19:15:37.456694 git.c:348               trace: built-in: git
>> 'rev-parse' '--verify' '-q' 'HEAD'
>
>
> For reference, I found an existing mailing list discussion on this
> from a few years ago:
> http://git.661346.n2.nabble.com/Interactive-rebase-with-submodules-td7197519.html
>
> Apparently a patch was proposed, i do not know if it made it in a
> release of Git. But based on what I'm seeing right now, it seems that
> it did not.

Nope, this patch made it in at the a6754cda change John mentioned.
But while working on recursive submodule update I got the impression
that possibly some of the '--ignore-submodule' options used in the
git scripts should be changed to '--ignore-submodule=dirty', but I
didn't find the time yet to confirm that hypothesis (I'm currently
concentrating on those builtins that use unpack_trees() directly).

Re: Rebasing with submodule change causes red herring with --continue

[John Keeping]

On Thu, Apr 23, 2015 at 09:43:44PM +0200, Jens Lehmann wrote:
> Am 23.04.2015 um 21:07 schrieb Robert Dailey:
> > On Thu, Apr 23, 2015 at 1:17 PM, Robert Dailey <rcdailey.lists@gmail.com> wrote:
> >> On Fri, Apr 10, 2015 at 11:44 AM, John Keeping <john@keeping.me.uk> wrote:
> >>> On Fri, Apr 10, 2015 at 11:30:20AM -0500, Robert Dailey wrote:
> >>>> I have a branch that contains a commit with a single change: A
> >>>> submodule pointing to a new SHA1.
> >>>>
> >>>> When I rebase this branch onto the tip of its parent branch AND that
> >>>> parent branch had modified that same submodule, the rebase stops at
> >>>> the commit on my branch that modified the submodule and asks me if I
> >>>> want to keep REMOTE or LOCAL. I say LOCAL and notice immediately that
> >>>> the submodule is not staged (normally it would be).
> >>>>
> >>>> I do:
> >>>>
> >>>> $ git add my-submodule
> >>>>
> >>>> Then I do:
> >>>>
> >>>> $ git rebase --continue
> >>>>
> >>>> At this point, it fails asking me if I forgot to stage changes and
> >>>> recommends doing --skip. This is normally what you would see if the
> >>>> staging area was completely empty, however it isn't, since I see the
> >>>> submodule is in there.
> >>>>
> >>>> Is this a bug or am I missing a fundamental here? I'm using Git 2.1.0
> >>>> on Windows through MSYS. I'll provide more concrete examples if my
> >>>> summary of the issue doesn't "ring any bells".
> >>>
> >>> I hit something similar in the past, but it was fixed with commit
> >>> a6754cd (rebase -i continue: don't skip commits that only change
> >>> submodules, 2012-04-07) so I think you must be hitting a slightly
> >>> different problem, although the tests added in that commit look like
> >>> they do test the scenario you describe (specifically 'rebase -i continue
> >>> with only submodule staged').
> >>
> >> I am still running into this issue on git 2.3.5 on Windows. Logs
> >> below. One interesting thing to note in the git trace output is that
> >> it is specifying --ignore-submodules option to `git diff-files` during
> >> the rebase continue. Is this due to a configuration option? It seems
> >> like git should not be ignoring submodules when continuing a rebase
> >> (this should only affect direct calls to diff)
> >>
> >>
> >> |-- Robert@M5536:/e/code/frontend (timeline-ids-develop|REBASE 3/3) --|
> >> $ git status
> >> rebase in progress; onto bb05e7c
> >> You are currently rebasing branch 'timeline-ids-develop' on 'bb05e7c'.
> >>    (all conflicts fixed: run "git rebase --continue")
> >>
> >> Changes to be committed:
> >>    (use "git reset HEAD <file>..." to unstage)
> >>
> >>          modified:   Core
> >>
> >> Changes not staged for commit:
> >>    (use "git add <file>..." to update what will be committed)
> >>    (use "git checkout -- <file>..." to discard changes in working directory)
> >>
> >>          modified:   Core (new commits)
> >>
> >> Untracked files:
> >>    (use "git add <file>..." to include in what will be committed)
> >>
> >>          Tools/FontTool/
> >>
> >>
> >> |-- Robert@M5536:/e/code/frontend (timeline-ids-develop|REBASE 3/3) --|
> >> $ GIT_TRACE=1 git rebase --continue
> >> 19:15:33.569945 git.c:557               trace: exec: 'git-rebase' '--continue'
> >> 19:15:33.569945 run-command.c:351       trace: run_command:
> >> 'git-rebase' '--continue'
> >> 19:15:33.775097 git.c:348               trace: built-in: git
> >> 'rev-parse' '--parseopt' '--stuck-long' '--' '--continue'
> >> 19:15:33.931190 git.c:348               trace: built-in: git
> >> 'rev-parse' '--git-dir'
> >> 19:15:34.007242 git.c:348               trace: built-in: git
> >> 'rev-parse' '--is-bare-repository'
> >> 19:15:34.059280 git.c:348               trace: built-in: git
> >> 'rev-parse' '--show-toplevel'
> >> 19:15:34.148343 git.c:348               trace: built-in: git 'config'
> >> '--bool' 'rebase.stat'
> >> 19:15:34.227399 git.c:348               trace: built-in: git 'config'
> >> '--bool' 'rebase.autostash'
> >> 19:15:34.280437 git.c:348               trace: built-in: git 'config'
> >> '--bool' 'rebase.autosquash'
> >> 19:15:34.335476 git.c:348               trace: built-in: git
> >> 'rev-parse' '--verify' 'HEAD'
> >> 19:15:34.389515 git.c:348               trace: built-in: git
> >> 'update-index' '--ignore-submodules' '--refresh'
> >> 19:15:34.554631 git.c:348               trace: built-in: git
> >> 'diff-files' '--quiet' '--ignore-submodules'
> >> 19:15:34.902879 git.c:557               trace: exec: 'git-am'
> >> '--resolved' '--resolvemsg=
> >> When you have resolved this problem, run "git rebase --continue".
> >> If you prefer to skip this patch, run "git rebase --skip" instead.
> >> To check out the original branch and stop rebasing, run "git rebase --abort".
> >> '
> >> 19:15:34.902879 run-command.c:351       trace: run_command: 'git-am'
> >> '--resolved' '--resolvemsg=
> >> When you have resolved this problem, run "git rebase --continue".
> >> If you prefer to skip this patch, run "git rebase --skip" instead.
> >> To check out the original branch and stop rebasing, run "git rebase --abort".
> >> '
> >> 19:15:35.113028 git.c:348               trace: built-in: git
> >> 'rev-parse' '--parseopt' '--stuck-long' '--' '--resolved'
> >> '--resolvemsg=
> >> When you have resolved this problem, run "git rebase --continue".
> >> If you prefer to skip this patch, run "git rebase --skip" instead.
> >> To check out the original branch and stop rebasing, run "git rebase --abort".
> >> '
> >> 19:15:35.290155 git.c:348               trace: built-in: git
> >> 'rev-parse' '--git-dir'
> >> 19:15:35.387224 git.c:348               trace: built-in: git
> >> 'rev-parse' '--show-prefix'
> >> 19:15:35.541332 git.c:348               trace: built-in: git
> >> 'rev-parse' '--show-toplevel'
> >> 19:15:35.598374 git.c:348               trace: built-in: git 'var'
> >> 'GIT_COMMITTER_IDENT'
> >> 19:15:35.659417 git.c:348               trace: built-in: git
> >> 'rev-parse' '--verify' '-q' 'HEAD'
> >> 19:15:35.724462 git.c:348               trace: built-in: git 'config'
> >> '--bool' '--get' 'am.messageid'
> >> 19:15:35.811524 git.c:348               trace: built-in: git 'config'
> >> '--bool' '--get' 'am.keepcr'
> >> 19:15:36.037685 git.c:348               trace: built-in: git
> >> 'update-index' '-q' '--refresh'
> >> 19:15:37.057409 git.c:557               trace: exec:
> >> 'git-sh-i18n--envsubst' '--variables' 'Applying: $FIRSTLINE'
> >> 19:15:37.057409 run-command.c:351       trace: run_command:
> >> 'git-sh-i18n--envsubst' '--variables' 'Applying: $FIRSTLINE'
> >> 19:15:37.178495 git.c:557               trace: exec:
> >> 'git-sh-i18n--envsubst' 'Applying: $FIRSTLINE'
> >> 19:15:37.178495 run-command.c:351       trace: run_command:
> >> 'git-sh-i18n--envsubst' 'Applying: $FIRSTLINE'
> >> Applying: TEMP: Update Core submodule
> >> 19:15:37.360624 git.c:348               trace: built-in: git
> >> 'diff-index' '--ignore-submodules' '--quiet' '--cached' 'HEAD' '--'
> >> No changes - did you forget to use 'git add'?
> >> If there is nothing left to stage, chances are that something else
> >> already introduced the same changes; you might want to skip this patch.
> >>
> >> When you have resolved this problem, run "git rebase --continue".
> >> If you prefer to skip this patch, run "git rebase --skip" instead.
> >> To check out the original branch and stop rebasing, run "git rebase --abort".
> >>
> >> 19:15:37.456694 git.c:348               trace: built-in: git
> >> 'rev-parse' '--verify' '-q' 'HEAD'
> >
> >
> > For reference, I found an existing mailing list discussion on this
> > from a few years ago:
> > http://git.661346.n2.nabble.com/Interactive-rebase-with-submodules-td7197519.html
> >
> > Apparently a patch was proposed, i do not know if it made it in a
> > release of Git. But based on what I'm seeing right now, it seems that
> > it did not.
> 
> Nope, this patch made it in at the a6754cda change John mentioned.
> But while working on recursive submodule update I got the impression
> that possibly some of the '--ignore-submodule' options used in the
> git scripts should be changed to '--ignore-submodule=dirty', but I
> didn't find the time yet to confirm that hypothesis (I'm currently
> concentrating on those builtins that use unpack_trees() directly).

I think the difference is that Robert isn't going through the
interactive codepath.  a6754cda affects git-rebase--interactive.sh which
no longer contains --ignore-submodules at all, but git-rebase.sh does
use it at the beginning of the "rebase --continue" case.

So if you're continuing an interactive rebase you go:

	git update-index --ignore-submodules --refresh &&
	git diff-files --quiet --ignore-submodules || {
		echo "$(gettext "You must edit all merge conflicts and then
mark them as resolved using git add")"
		exit 1
	}
	
and then jump into git-rebase--interactive.sh which checks for any
cached changes (including submodules) before deciding what to do.

But if the rebase isn't interactive it goes to git-am which results in
the message above.

So it seems a change similar to a6754cda is needed in git-am in order to
fix this for non-interactive rebases (and presumably plain "git am
--continue" if only submodule changes are staged).

However, I can't figure out how the code results in the trace above.  On
master (v2.4.0-rc2-43-gfb89636) the "Applying: $FIRSTLINE" comes from
line 843 of git-am.sh so the diff-index invocation should be the one on
line 863, which matches the message printed.  But that invocation
doesn't pass --ignore-submodules and AFAICT never has (at least in
vanilla Git).

Re: Rebasing with submodule change causes red herring with --continue

[John Keeping]

On Thu, Apr 23, 2015 at 09:35:38PM +0100, John Keeping wrote:
> On Thu, Apr 23, 2015 at 09:43:44PM +0200, Jens Lehmann wrote:
> > Am 23.04.2015 um 21:07 schrieb Robert Dailey:
> > > On Thu, Apr 23, 2015 at 1:17 PM, Robert Dailey <rcdailey.lists@gmail.com> wrote:
> > >> On Fri, Apr 10, 2015 at 11:44 AM, John Keeping <john@keeping.me.uk> wrote:
> > >>> On Fri, Apr 10, 2015 at 11:30:20AM -0500, Robert Dailey wrote:
> > >>>> I have a branch that contains a commit with a single change: A
> > >>>> submodule pointing to a new SHA1.
> > >>>>
> > >>>> When I rebase this branch onto the tip of its parent branch AND that
> > >>>> parent branch had modified that same submodule, the rebase stops at
> > >>>> the commit on my branch that modified the submodule and asks me if I
> > >>>> want to keep REMOTE or LOCAL. I say LOCAL and notice immediately that
> > >>>> the submodule is not staged (normally it would be).
> > >>>>
> > >>>> I do:
> > >>>>
> > >>>> $ git add my-submodule
> > >>>>
> > >>>> Then I do:
> > >>>>
> > >>>> $ git rebase --continue
> > >>>>
> > >>>> At this point, it fails asking me if I forgot to stage changes and
> > >>>> recommends doing --skip. This is normally what you would see if the
> > >>>> staging area was completely empty, however it isn't, since I see the
> > >>>> submodule is in there.
> > >>>>
> > >>>> Is this a bug or am I missing a fundamental here? I'm using Git 2.1.0
> > >>>> on Windows through MSYS. I'll provide more concrete examples if my
> > >>>> summary of the issue doesn't "ring any bells".
> > >>>
> > >>> I hit something similar in the past, but it was fixed with commit
> > >>> a6754cd (rebase -i continue: don't skip commits that only change
> > >>> submodules, 2012-04-07) so I think you must be hitting a slightly
> > >>> different problem, although the tests added in that commit look like
> > >>> they do test the scenario you describe (specifically 'rebase -i continue
> > >>> with only submodule staged').
> > >>
> > >> I am still running into this issue on git 2.3.5 on Windows. Logs
> > >> below. One interesting thing to note in the git trace output is that
> > >> it is specifying --ignore-submodules option to `git diff-files` during
> > >> the rebase continue. Is this due to a configuration option? It seems
> > >> like git should not be ignoring submodules when continuing a rebase
> > >> (this should only affect direct calls to diff)
> > >>
> > >>
> > >> |-- Robert@M5536:/e/code/frontend (timeline-ids-develop|REBASE 3/3) --|
> > >> $ git status
> > >> rebase in progress; onto bb05e7c
> > >> You are currently rebasing branch 'timeline-ids-develop' on 'bb05e7c'.
> > >>    (all conflicts fixed: run "git rebase --continue")
> > >>
> > >> Changes to be committed:
> > >>    (use "git reset HEAD <file>..." to unstage)
> > >>
> > >>          modified:   Core
> > >>
> > >> Changes not staged for commit:
> > >>    (use "git add <file>..." to update what will be committed)
> > >>    (use "git checkout -- <file>..." to discard changes in working directory)
> > >>
> > >>          modified:   Core (new commits)
> > >>
> > >> Untracked files:
> > >>    (use "git add <file>..." to include in what will be committed)
> > >>
> > >>          Tools/FontTool/
> > >>
> > >>
> > >> |-- Robert@M5536:/e/code/frontend (timeline-ids-develop|REBASE 3/3) --|
> > >> $ GIT_TRACE=1 git rebase --continue
> > >> 19:15:33.569945 git.c:557               trace: exec: 'git-rebase' '--continue'
> > >> 19:15:33.569945 run-command.c:351       trace: run_command:
> > >> 'git-rebase' '--continue'
> > >> 19:15:33.775097 git.c:348               trace: built-in: git
> > >> 'rev-parse' '--parseopt' '--stuck-long' '--' '--continue'
> > >> 19:15:33.931190 git.c:348               trace: built-in: git
> > >> 'rev-parse' '--git-dir'
> > >> 19:15:34.007242 git.c:348               trace: built-in: git
> > >> 'rev-parse' '--is-bare-repository'
> > >> 19:15:34.059280 git.c:348               trace: built-in: git
> > >> 'rev-parse' '--show-toplevel'
> > >> 19:15:34.148343 git.c:348               trace: built-in: git 'config'
> > >> '--bool' 'rebase.stat'
> > >> 19:15:34.227399 git.c:348               trace: built-in: git 'config'
> > >> '--bool' 'rebase.autostash'
> > >> 19:15:34.280437 git.c:348               trace: built-in: git 'config'
> > >> '--bool' 'rebase.autosquash'
> > >> 19:15:34.335476 git.c:348               trace: built-in: git
> > >> 'rev-parse' '--verify' 'HEAD'
> > >> 19:15:34.389515 git.c:348               trace: built-in: git
> > >> 'update-index' '--ignore-submodules' '--refresh'
> > >> 19:15:34.554631 git.c:348               trace: built-in: git
> > >> 'diff-files' '--quiet' '--ignore-submodules'
> > >> 19:15:34.902879 git.c:557               trace: exec: 'git-am'
> > >> '--resolved' '--resolvemsg=
> > >> When you have resolved this problem, run "git rebase --continue".
> > >> If you prefer to skip this patch, run "git rebase --skip" instead.
> > >> To check out the original branch and stop rebasing, run "git rebase --abort".
> > >> '
> > >> 19:15:34.902879 run-command.c:351       trace: run_command: 'git-am'
> > >> '--resolved' '--resolvemsg=
> > >> When you have resolved this problem, run "git rebase --continue".
> > >> If you prefer to skip this patch, run "git rebase --skip" instead.
> > >> To check out the original branch and stop rebasing, run "git rebase --abort".
> > >> '
> > >> 19:15:35.113028 git.c:348               trace: built-in: git
> > >> 'rev-parse' '--parseopt' '--stuck-long' '--' '--resolved'
> > >> '--resolvemsg=
> > >> When you have resolved this problem, run "git rebase --continue".
> > >> If you prefer to skip this patch, run "git rebase --skip" instead.
> > >> To check out the original branch and stop rebasing, run "git rebase --abort".
> > >> '
> > >> 19:15:35.290155 git.c:348               trace: built-in: git
> > >> 'rev-parse' '--git-dir'
> > >> 19:15:35.387224 git.c:348               trace: built-in: git
> > >> 'rev-parse' '--show-prefix'
> > >> 19:15:35.541332 git.c:348               trace: built-in: git
> > >> 'rev-parse' '--show-toplevel'
> > >> 19:15:35.598374 git.c:348               trace: built-in: git 'var'
> > >> 'GIT_COMMITTER_IDENT'
> > >> 19:15:35.659417 git.c:348               trace: built-in: git
> > >> 'rev-parse' '--verify' '-q' 'HEAD'
> > >> 19:15:35.724462 git.c:348               trace: built-in: git 'config'
> > >> '--bool' '--get' 'am.messageid'
> > >> 19:15:35.811524 git.c:348               trace: built-in: git 'config'
> > >> '--bool' '--get' 'am.keepcr'
> > >> 19:15:36.037685 git.c:348               trace: built-in: git
> > >> 'update-index' '-q' '--refresh'
> > >> 19:15:37.057409 git.c:557               trace: exec:
> > >> 'git-sh-i18n--envsubst' '--variables' 'Applying: $FIRSTLINE'
> > >> 19:15:37.057409 run-command.c:351       trace: run_command:
> > >> 'git-sh-i18n--envsubst' '--variables' 'Applying: $FIRSTLINE'
> > >> 19:15:37.178495 git.c:557               trace: exec:
> > >> 'git-sh-i18n--envsubst' 'Applying: $FIRSTLINE'
> > >> 19:15:37.178495 run-command.c:351       trace: run_command:
> > >> 'git-sh-i18n--envsubst' 'Applying: $FIRSTLINE'
> > >> Applying: TEMP: Update Core submodule
> > >> 19:15:37.360624 git.c:348               trace: built-in: git
> > >> 'diff-index' '--ignore-submodules' '--quiet' '--cached' 'HEAD' '--'
> > >> No changes - did you forget to use 'git add'?
> > >> If there is nothing left to stage, chances are that something else
> > >> already introduced the same changes; you might want to skip this patch.
> > >>
> > >> When you have resolved this problem, run "git rebase --continue".
> > >> If you prefer to skip this patch, run "git rebase --skip" instead.
> > >> To check out the original branch and stop rebasing, run "git rebase --abort".
> > >>
> > >> 19:15:37.456694 git.c:348               trace: built-in: git
> > >> 'rev-parse' '--verify' '-q' 'HEAD'
> > >
> > >
> > > For reference, I found an existing mailing list discussion on this
> > > from a few years ago:
> > > http://git.661346.n2.nabble.com/Interactive-rebase-with-submodules-td7197519.html
> > >
> > > Apparently a patch was proposed, i do not know if it made it in a
> > > release of Git. But based on what I'm seeing right now, it seems that
> > > it did not.
> > 
> > Nope, this patch made it in at the a6754cda change John mentioned.
> > But while working on recursive submodule update I got the impression
> > that possibly some of the '--ignore-submodule' options used in the
> > git scripts should be changed to '--ignore-submodule=dirty', but I
> > didn't find the time yet to confirm that hypothesis (I'm currently
> > concentrating on those builtins that use unpack_trees() directly).
> 
> I think the difference is that Robert isn't going through the
> interactive codepath.  a6754cda affects git-rebase--interactive.sh which
> no longer contains --ignore-submodules at all, but git-rebase.sh does
> use it at the beginning of the "rebase --continue" case.
> 
> So if you're continuing an interactive rebase you go:
> 
> 	git update-index --ignore-submodules --refresh &&
> 	git diff-files --quiet --ignore-submodules || {
> 		echo "$(gettext "You must edit all merge conflicts and then
> mark them as resolved using git add")"
> 		exit 1
> 	}
> 	
> and then jump into git-rebase--interactive.sh which checks for any
> cached changes (including submodules) before deciding what to do.
> 
> But if the rebase isn't interactive it goes to git-am which results in
> the message above.
> 
> So it seems a change similar to a6754cda is needed in git-am in order to
> fix this for non-interactive rebases (and presumably plain "git am
> --continue" if only submodule changes are staged).
> 
> However, I can't figure out how the code results in the trace above.  On
> master (v2.4.0-rc2-43-gfb89636) the "Applying: $FIRSTLINE" comes from
> line 843 of git-am.sh so the diff-index invocation should be the one on
> line 863, which matches the message printed.  But that invocation
> doesn't pass --ignore-submodules and AFAICT never has (at least in
> vanilla Git).

It looks like this comes from a change in msysgit/git [0] that isn't in
upstream git.git.

[0] https://github.com/msysgit/git/commit/fbe1f041f9890f4b2eea3ed2265f82c9b845a39b

Re: Rebasing with submodule change causes red herring with --continue

[Robert Dailey]

On Thu, Apr 23, 2015 at 5:43 PM, John Keeping <john@keeping.me.uk> wrote:
> On Thu, Apr 23, 2015 at 09:35:38PM +0100, John Keeping wrote:
>> On Thu, Apr 23, 2015 at 09:43:44PM +0200, Jens Lehmann wrote:
>> > Am 23.04.2015 um 21:07 schrieb Robert Dailey:
>> > > On Thu, Apr 23, 2015 at 1:17 PM, Robert Dailey <rcdailey.lists@gmail.com> wrote:
>> > >> On Fri, Apr 10, 2015 at 11:44 AM, John Keeping <john@keeping.me.uk> wrote:
>> > >>> On Fri, Apr 10, 2015 at 11:30:20AM -0500, Robert Dailey wrote:
>> > >>>> I have a branch that contains a commit with a single change: A
>> > >>>> submodule pointing to a new SHA1.
>> > >>>>
>> > >>>> When I rebase this branch onto the tip of its parent branch AND that
>> > >>>> parent branch had modified that same submodule, the rebase stops at
>> > >>>> the commit on my branch that modified the submodule and asks me if I
>> > >>>> want to keep REMOTE or LOCAL. I say LOCAL and notice immediately that
>> > >>>> the submodule is not staged (normally it would be).
>> > >>>>
>> > >>>> I do:
>> > >>>>
>> > >>>> $ git add my-submodule
>> > >>>>
>> > >>>> Then I do:
>> > >>>>
>> > >>>> $ git rebase --continue
>> > >>>>
>> > >>>> At this point, it fails asking me if I forgot to stage changes and
>> > >>>> recommends doing --skip. This is normally what you would see if the
>> > >>>> staging area was completely empty, however it isn't, since I see the
>> > >>>> submodule is in there.
>> > >>>>
>> > >>>> Is this a bug or am I missing a fundamental here? I'm using Git 2.1.0
>> > >>>> on Windows through MSYS. I'll provide more concrete examples if my
>> > >>>> summary of the issue doesn't "ring any bells".
>> > >>>
>> > >>> I hit something similar in the past, but it was fixed with commit
>> > >>> a6754cd (rebase -i continue: don't skip commits that only change
>> > >>> submodules, 2012-04-07) so I think you must be hitting a slightly
>> > >>> different problem, although the tests added in that commit look like
>> > >>> they do test the scenario you describe (specifically 'rebase -i continue
>> > >>> with only submodule staged').
>> > >>
>> > >> I am still running into this issue on git 2.3.5 on Windows. Logs
>> > >> below. One interesting thing to note in the git trace output is that
>> > >> it is specifying --ignore-submodules option to `git diff-files` during
>> > >> the rebase continue. Is this due to a configuration option? It seems
>> > >> like git should not be ignoring submodules when continuing a rebase
>> > >> (this should only affect direct calls to diff)
>> > >>
>> > >>
>> > >> |-- Robert@M5536:/e/code/frontend (timeline-ids-develop|REBASE 3/3) --|
>> > >> $ git status
>> > >> rebase in progress; onto bb05e7c
>> > >> You are currently rebasing branch 'timeline-ids-develop' on 'bb05e7c'.
>> > >>    (all conflicts fixed: run "git rebase --continue")
>> > >>
>> > >> Changes to be committed:
>> > >>    (use "git reset HEAD <file>..." to unstage)
>> > >>
>> > >>          modified:   Core
>> > >>
>> > >> Changes not staged for commit:
>> > >>    (use "git add <file>..." to update what will be committed)
>> > >>    (use "git checkout -- <file>..." to discard changes in working directory)
>> > >>
>> > >>          modified:   Core (new commits)
>> > >>
>> > >> Untracked files:
>> > >>    (use "git add <file>..." to include in what will be committed)
>> > >>
>> > >>          Tools/FontTool/
>> > >>
>> > >>
>> > >> |-- Robert@M5536:/e/code/frontend (timeline-ids-develop|REBASE 3/3) --|
>> > >> $ GIT_TRACE=1 git rebase --continue
>> > >> 19:15:33.569945 git.c:557               trace: exec: 'git-rebase' '--continue'
>> > >> 19:15:33.569945 run-command.c:351       trace: run_command:
>> > >> 'git-rebase' '--continue'
>> > >> 19:15:33.775097 git.c:348               trace: built-in: git
>> > >> 'rev-parse' '--parseopt' '--stuck-long' '--' '--continue'
>> > >> 19:15:33.931190 git.c:348               trace: built-in: git
>> > >> 'rev-parse' '--git-dir'
>> > >> 19:15:34.007242 git.c:348               trace: built-in: git
>> > >> 'rev-parse' '--is-bare-repository'
>> > >> 19:15:34.059280 git.c:348               trace: built-in: git
>> > >> 'rev-parse' '--show-toplevel'
>> > >> 19:15:34.148343 git.c:348               trace: built-in: git 'config'
>> > >> '--bool' 'rebase.stat'
>> > >> 19:15:34.227399 git.c:348               trace: built-in: git 'config'
>> > >> '--bool' 'rebase.autostash'
>> > >> 19:15:34.280437 git.c:348               trace: built-in: git 'config'
>> > >> '--bool' 'rebase.autosquash'
>> > >> 19:15:34.335476 git.c:348               trace: built-in: git
>> > >> 'rev-parse' '--verify' 'HEAD'
>> > >> 19:15:34.389515 git.c:348               trace: built-in: git
>> > >> 'update-index' '--ignore-submodules' '--refresh'
>> > >> 19:15:34.554631 git.c:348               trace: built-in: git
>> > >> 'diff-files' '--quiet' '--ignore-submodules'
>> > >> 19:15:34.902879 git.c:557               trace: exec: 'git-am'
>> > >> '--resolved' '--resolvemsg=
>> > >> When you have resolved this problem, run "git rebase --continue".
>> > >> If you prefer to skip this patch, run "git rebase --skip" instead.
>> > >> To check out the original branch and stop rebasing, run "git rebase --abort".
>> > >> '
>> > >> 19:15:34.902879 run-command.c:351       trace: run_command: 'git-am'
>> > >> '--resolved' '--resolvemsg=
>> > >> When you have resolved this problem, run "git rebase --continue".
>> > >> If you prefer to skip this patch, run "git rebase --skip" instead.
>> > >> To check out the original branch and stop rebasing, run "git rebase --abort".
>> > >> '
>> > >> 19:15:35.113028 git.c:348               trace: built-in: git
>> > >> 'rev-parse' '--parseopt' '--stuck-long' '--' '--resolved'
>> > >> '--resolvemsg=
>> > >> When you have resolved this problem, run "git rebase --continue".
>> > >> If you prefer to skip this patch, run "git rebase --skip" instead.
>> > >> To check out the original branch and stop rebasing, run "git rebase --abort".
>> > >> '
>> > >> 19:15:35.290155 git.c:348               trace: built-in: git
>> > >> 'rev-parse' '--git-dir'
>> > >> 19:15:35.387224 git.c:348               trace: built-in: git
>> > >> 'rev-parse' '--show-prefix'
>> > >> 19:15:35.541332 git.c:348               trace: built-in: git
>> > >> 'rev-parse' '--show-toplevel'
>> > >> 19:15:35.598374 git.c:348               trace: built-in: git 'var'
>> > >> 'GIT_COMMITTER_IDENT'
>> > >> 19:15:35.659417 git.c:348               trace: built-in: git
>> > >> 'rev-parse' '--verify' '-q' 'HEAD'
>> > >> 19:15:35.724462 git.c:348               trace: built-in: git 'config'
>> > >> '--bool' '--get' 'am.messageid'
>> > >> 19:15:35.811524 git.c:348               trace: built-in: git 'config'
>> > >> '--bool' '--get' 'am.keepcr'
>> > >> 19:15:36.037685 git.c:348               trace: built-in: git
>> > >> 'update-index' '-q' '--refresh'
>> > >> 19:15:37.057409 git.c:557               trace: exec:
>> > >> 'git-sh-i18n--envsubst' '--variables' 'Applying: $FIRSTLINE'
>> > >> 19:15:37.057409 run-command.c:351       trace: run_command:
>> > >> 'git-sh-i18n--envsubst' '--variables' 'Applying: $FIRSTLINE'
>> > >> 19:15:37.178495 git.c:557               trace: exec:
>> > >> 'git-sh-i18n--envsubst' 'Applying: $FIRSTLINE'
>> > >> 19:15:37.178495 run-command.c:351       trace: run_command:
>> > >> 'git-sh-i18n--envsubst' 'Applying: $FIRSTLINE'
>> > >> Applying: TEMP: Update Core submodule
>> > >> 19:15:37.360624 git.c:348               trace: built-in: git
>> > >> 'diff-index' '--ignore-submodules' '--quiet' '--cached' 'HEAD' '--'
>> > >> No changes - did you forget to use 'git add'?
>> > >> If there is nothing left to stage, chances are that something else
>> > >> already introduced the same changes; you might want to skip this patch.
>> > >>
>> > >> When you have resolved this problem, run "git rebase --continue".
>> > >> If you prefer to skip this patch, run "git rebase --skip" instead.
>> > >> To check out the original branch and stop rebasing, run "git rebase --abort".
>> > >>
>> > >> 19:15:37.456694 git.c:348               trace: built-in: git
>> > >> 'rev-parse' '--verify' '-q' 'HEAD'
>> > >
>> > >
>> > > For reference, I found an existing mailing list discussion on this
>> > > from a few years ago:
>> > > http://git.661346.n2.nabble.com/Interactive-rebase-with-submodules-td7197519.html
>> > >
>> > > Apparently a patch was proposed, i do not know if it made it in a
>> > > release of Git. But based on what I'm seeing right now, it seems that
>> > > it did not.
>> >
>> > Nope, this patch made it in at the a6754cda change John mentioned.
>> > But while working on recursive submodule update I got the impression
>> > that possibly some of the '--ignore-submodule' options used in the
>> > git scripts should be changed to '--ignore-submodule=dirty', but I
>> > didn't find the time yet to confirm that hypothesis (I'm currently
>> > concentrating on those builtins that use unpack_trees() directly).
>>
>> I think the difference is that Robert isn't going through the
>> interactive codepath.  a6754cda affects git-rebase--interactive.sh which
>> no longer contains --ignore-submodules at all, but git-rebase.sh does
>> use it at the beginning of the "rebase --continue" case.
>>
>> So if you're continuing an interactive rebase you go:
>>
>>       git update-index --ignore-submodules --refresh &&
>>       git diff-files --quiet --ignore-submodules || {
>>               echo "$(gettext "You must edit all merge conflicts and then
>> mark them as resolved using git add")"
>>               exit 1
>>       }
>>
>> and then jump into git-rebase--interactive.sh which checks for any
>> cached changes (including submodules) before deciding what to do.
>>
>> But if the rebase isn't interactive it goes to git-am which results in
>> the message above.
>>
>> So it seems a change similar to a6754cda is needed in git-am in order to
>> fix this for non-interactive rebases (and presumably plain "git am
>> --continue" if only submodule changes are staged).
>>
>> However, I can't figure out how the code results in the trace above.  On
>> master (v2.4.0-rc2-43-gfb89636) the "Applying: $FIRSTLINE" comes from
>> line 843 of git-am.sh so the diff-index invocation should be the one on
>> line 863, which matches the message printed.  But that invocation
>> doesn't pass --ignore-submodules and AFAICT never has (at least in
>> vanilla Git).
>
> It looks like this comes from a change in msysgit/git [0] that isn't in
> upstream git.git.
>
> [0] https://github.com/msysgit/git/commit/fbe1f041f9890f4b2eea3ed2265f82c9b845a39b

Thanks guys; I worked with the developers on the Git for Windows
project and they have reverted that commit.