"brian m. carlson" <sandals@xxxxxxxxxxxxxxxxxxxx> 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. Cc'ing some folks who recently mumbled the word "submodule" in their recent topics for input. Thanks.
