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

["brian m. carlson" <sandals@crustytoothpaste.net>]

[-- Attachment #1: Type: text/plain, Size: 1685 bytes --]

On 2021-06-16 at 13:20:44, Philippe Blain wrote:
> Hi all,
> 
> Le 2021-06-15 à 23:10, Junio C Hamano a écrit :
> > "brian m. carlson" <sandals@crustytoothpaste.net> writes:
> > 
> > > 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].

I have a patch along this line and am looking into some test failures,
so it's not that I've forgotten about it, but that it is, as usual, not
as trivial as I'd hoped.  It may take me until the weekend to come up
with something nice.

Our problem seems to be that once we mark it as inactive, we never end
up initializing the repository even if something like --checkout is
passed (at least in the tests), so I'm trying to come up with an elegant
way to deal with that.
-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]