On Mon, Nov 6, 2017 at 8:37 PM, Brandon Williams <bmwill@xxxxxxxxxx> wrote: > After reading your bug report and the fact that you weren't able to > reproduce it outside of your project I think i figured out what is > happening. Before ff6f1f564c the gitmodules file wasn't being loaded > unless a codepath explicitly wanted to work with submodules. Now they > are being lazy-loaded so if you call into the submodule config subsystem > it'll work without having to have initialized it before. I suspect > that the submodule which is causing the failure has a > "submodule.<name>.ignore" entry in the .gitmodules file or somewhere in > your repositories config (I actually suspect the latter based on the > code path). > > When rebase calls into the diff machinery to see if there are unstaged > changes it explicitly requests that submodule's be ignored, but this > desired gets overridden by your repository's config, clearing the > ignored flag and making rebase actually pay attention to the fact that > the submodule has changes in it. > > I don't have a patch available to for you to test just yet (but I'll > have some time later today to write one up) but could you verify that > (1) you have an ignore entry for the submodule in question in your > config and (2) removing it from your config avoids the failure? If > that's the case then we would be able to put together a reproducible > recipe for this failure. You're right. Thanks for the info. I have ignore = dirty, and removing it from the config solves the problem indeed. The following script reproduces the bug (it's the same as before, only added git config): rm -rf super sub mkdir sub; cd sub; git init git commit --allow-empty -m 'Initial commit' mkdir ../super; cd ../super git init git submodule add ../sub git config submodule.sub.ignore dirty touch foo; git add foo sub git commit -m 'Initial commit' touch a; git add a; git commit -m 'a' touch b; git add b; git commit -m 'b' cd sub; git commit --allow-empty -m 'New commit'; cd .. git rebase -i HEAD^^ - Orgad
