Re: [PATCH] submodule: mark submodules with update=none as inactive

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

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

On 2021-06-22 at 03:45:45, Philippe Blain wrote:
> > That will make us properly ignore the submodule
> > when performing recursive operations.
> > 
> > Note that we only do this when the --require-init option is passed,
> > which is only passed during clone.  That's because the update-clone
> > submodule helper is also invoked during a user-invoked git submodule
> > update, where we explicitly indicate that we override the configuration
> > setting, so we don't want to set such a configuration option then.
> 
> I'm not sure what you mean here by 'where we explicitely indicate that we
> override the configuration setting'. For me, as I wrote above,
> 'git clone --recurse-submodules' and 'git clone' followed by
> 'git submodule update --init' should lead to mostly [*] the same end result.
> 
> If you mean 'git submodule update --checkout', that indeed seems to sometimes override the 'update=none'
> configuration (a fact which is absent from the documentation), then it's true that we
> would not want to write 'active=false' at that invocation. As an aside, in my limited testing
> I could not always get 'git submodule update --checkout' to clone and checkout 'update=none' submdules;
> it would fail with "fatal: could not get a repository handle for submodule 'sub1'" because
> 'git checkout/reset --recurse-submodules' leaves a bad .git/modules/sub1/config file
> with the core.worktree setting when the command fails (this should not happen)...

Yes, that's what I meant.

> In any case, that leads me to think that maybe the right place to write the 'active' setting
> would be during 'git submodule init', thus builtin/submodule--helper.c::init_submodule ?
> This way it would lead to the same behaviour if the clone was recursive or not,
> and it would not interfere with 'git submodule update --checkout'.

Let me take a look at some other approaches and see if I can come up
with something a little bit better.

My apologies for the delay in response; I'm in the process of moving at
the moment and my attention has been directed elsewhere than the list.
-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA

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