Jens Lehmann [off-list ref] writes:
This should be fixed to be able to detect regressions in the future, so
I came up with replacing the "git submodule status submodule" calls with
"git status -s submodule", which did the trick for me.
Hmph, is that a bug in "git submodule status" or is the subcommand
deliberately designed to ignore this class of differences?
Am 17.02.2011 21:18, schrieb Junio C Hamano:
Jens Lehmann [off-list ref] writes:
quoted
This should be fixed to be able to detect regressions in the future, so
I came up with replacing the "git submodule status submodule" calls with
"git status -s submodule", which did the trick for me.
Hmph, is that a bug in "git submodule status" or is the subcommand
deliberately designed to ignore this class of differences?
The latter, it doesn't care about working tree modifications inside of
submodules as It uses the "--ignore-submodules=dirty" option when calling
"git diff-files" (I added that in 18076502). The reason for one test to
succeed and the other to fail is that the merge succeeds even though
the work tree is empty while rebase errors out. So "git submodule status"
is the wrong command to detect work tree differences, that's why we have
to use "git status" here.