Actually, nevermind that last comment. I misunderstood what `git submodule init` does. I thought it cloned missing submodules, but apparently that's done by `git submodule update`, so the behavior does make sense. On Tue, Jun 15, 2021 at 6:39 PM Rose Kunkel <rose@xxxxxxxxxxxxx> wrote: > > That sounds reasonable to me. > > I do think it's pretty unintuitive that `update = none` means that > submodules never get initialized, even with an explicit `git submodule > init` command. If this is intended behavior, it should be better > documented. If not, fixing that would also fix this bug. > > On Tue, Jun 15, 2021 at 6:25 PM brian m. carlson > <sandals@xxxxxxxxxxxxxxxxxxxx> wrote: > > > > 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. > > -- > > brian m. carlson (he/him or they/them) > > Toronto, Ontario, CA