Re: [BUG] `git reset --hard` fails with `update = none` submodules

[Philippe Blain <levraiphilippeblain@gmail.com>]

Hi all,

Le 2021-06-15 à 23:10, Junio C Hamano a écrit :
> "brian m. carlson" <sandals@crustytoothpaste.net> writes:
> 
>> On 2021-06-16 at 01:03:40, Rose Kunkel wrote:
>>> Potentially relevant: `git config --global --list` shows
>>> ```
>>> status.showstash=true
>>> status.submodulesummary=true
>>> submodule.recurse=true
>>
>> Thanks for this additional information.  This line is the critical
>> piece.  Now I get this:
>>
>>    $ git reset --hard
>>    fatal: not a git repository: ../../.git/modules/repos/agda
>>    fatal: could not reset submodule index
>>
>> Predictably, "git -c submodules.recurse=true reset --hard" also results
>> in the same thing.
>>
>> The --recurse-submodules option for git reset says this (emphasis mine):
>>
>>    When the working tree is updated, using --recurse-submodules will also
>>    recursively reset the working tree of all *active* submodules
>>    according to the commit recorded in the superproject, also setting the
>>    submodules' HEAD to be detached at that commit.
>>
>> On my system, .git/config has this:
>>
>>    [submodule]
>>            active = .
>>
>> So these submodules are active, but they probably should not be, since
>> we haven't checked anything out (or, for that matter, cloned any data)
>> and it wouldn't make sense to try to operate on them automatically with
>> submodules.recurse or --recurse-submodules.
>>
>> My gut tells me that we should probably mark submodules with update=none
>> set on a clone as inactive.  Of course, this is a tricky area that I'm
>> not super familiar with, so opinions or thoughts are welcome.
>>
>> If folks think this is a good way forward, I'll look into writing a
>> patch, probably tomorrow evening since it's starting to get late here.

This is probably a good fix. 'git clone --recurse-submodules' is really
too eager to write the 'submodule.active=.' config but it should be more careful;
the above is an example and [1] is another one.

I think it is a good way forward that having 'submodule.$name.update=none' in
'.gitmodules' means that 'git clone' would write 'submodule.$name.active=false'
to the local config. This way it would still be the case that 'submodule.$name.update'
itself only ever applies to 'git submodule update', which is what is documented [2].

A longer term plan could be to completely deprecate 'submodule.$name.update=none' and allow
'submodule.$name.active' in '.gitmodules'. Maybe anecdotal, but at least one user [3]
tried to do that and found out it does not work. Having 'active' allowed in '.gitmodules'
would (I think) cover all uses cases for 'update=none', which could then be deprecated,
but that would need a transition period. But this change is not necessarily needed; it
would just make the whole system more consistent IMO.

Cheers,

Philippe.
P.S. The current bug was reported last year [4] but I could not reproduce it at when I
replied. Adding '--force' to the 'git checkout other-branch' command in my reproducer
script does trigger the bug, though.


[1] https://lore.kernel.org/git/20200501005432.h62dnpkx7feb7rto@glandium.org/T/#u
[2] https://git-scm.com/docs/git-config#Documentation/git-config.txt-submoduleltnamegtupdate
[3] https://lore.kernel.org/git/HE1PR04MB2987A255BC327320D1DDFE6692F70@HE1PR04MB2987.eurprd04.prod.outlook.com/
[4] https://lore.kernel.org/git/CABVQXt5E-R22G62W-tQieA7XiZKZiOA8Hp2xewYhwwOS8wFh0Q@mail.gmail.com/