Hi all,
Le 2021-06-15 à 23:10, Junio C Hamano a écrit :
"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.
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@xxxxxxxxxxxx/T/#u
[2] https://git-scm.com/docs/git-config#Documentation/git-config.txt-submoduleltnamegtupdate
[3] https://lore.kernel.org/git/HE1PR04MB2987A255BC327320D1DDFE6692F70@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/
[4] https://lore.kernel.org/git/CABVQXt5E-R22G62W-tQieA7XiZKZiOA8Hp2xewYhwwOS8wFh0Q@xxxxxxxxxxxxxx/
