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

From: Philippe Blain <levraiphilippeblain@gmail.com>
Date: Jun 16, 2021, 13:20 UTC
Message-ID: <3b53846d-7611-521a-274c-473e00266529@gmail.com>
In-Reply-To: <xmqqeed2sdwc.fsf@gitster.g>

Hi all,

Le 2021-06-15 à 23:10, Junio C Hamano a écrit :

Show 42 quoted lines

> "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/