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

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Jun 17, 2021, 23:52 UTC
Message-ID: <YMvgRjwyrwyLz4SC@camp.crustytoothpaste.net>
In-Reply-To: <3b53846d-7611-521a-274c-473e00266529@gmail.com>

On 2021-06-16 at 13:20:44, Philippe Blain wrote:

Show 20 quoted lines

> 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