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

> 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.