Re: [BUG] `git reset --hard` fails with `update = none` submodules
flat view
From: Rose Kunkel <hidden>
Date: 2021-06-16 01:46:37
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 [off-list ref] 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 [off-list ref] wrote:quoted
On 2021-06-16 at 01:03:40, Rose Kunkel wrote:quoted
Potentially relevant: `git config --global --list` showsstatus.showstash=true status.submodulesummary=true submodule.recurse=trueThanks 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