On Sun, Jan 31, 2016 at 1:09 PM, Jens Lehmann <Jens.Lehmann@xxxxxx> wrote:
>>> After all this config is
>>> just about which submodules are chosen to be updated on clone and
>>> submodule update, not on all the other work tree manipulating
>>> commands.
>>
>>
>> So you'd imagine that "git submodule update" would remove the
>> submodule and setup an empty directory in case that submodule is
>> not configured ? (after switching branches or when just having cloned
>> that thing.)
>
>
> Not as a result of the label feature we are talking about here,
> I think that should just do what currently happens to removed
> submodules: they are left populated but are ignored by status,
> diff and submodule update. Removing the content is part of the
> recursive submodule update topic.
That is our second next big difference in understanding.
When having an autoInitialize option, we would not go further into
making rules for when to update submodules. "git submodule update"
would just update all initialzed submodules. (This thought ties well
together with only initializing those submodules that you want instead
of all of them.)
Now that we want to init all the submodules, it makes sense to only
update those we are interested in.
So from what I understand now:
(If labels are configured, then)
* init a submodule at the earliest time possible, (i.e. while
cloning or when upstream added a new submodule and
we fetch it? Though then the init would be performed not in
clone/fetch, but the "submodule update" step)
* never deinit submodules automatically
* submodule update is picky what to update by default.
It will only update by label selection or directly specified submodules
(git submodule update foo will update foo no matter if foo is in the
selected group, a plain "git submodule update" however will only
update group/label selected modules.)
>>>
>>>
>>> And throw away any customization the user did (to the URL or other
>>> configurations)?
>>>
>>> Without this sparse/label/group functionality, init is the way the
>>> user tells us he is interested in a submodule. But when configuring
>>> a label/name/path to update, the old meaning of init is obsolete
>>> and superseded by the new mechanism.
>>
>>
>> Or if we keep it at "--initSubmodule" only, which only initializes
>> a subset of new submodules, the meaning is not superseded.
>>
>> By having the initSubmodule thing set, the user tells us "I am interested
>> in all currently initialized submodules plus some more in the future, but
>> these have not arrived yet. To know which submodules I mean in the future
>> apply this pattern."
>>
>> Let's take the simplest case:
>>
>> A user is interested in all the submodules. So currently they clone
>> and initialize all of them. When upstream adds a new submodule, their
>> expectation is broken that all submodules are there and checked out.
>> by having the autoInit option, we'd just initialize any new submodule
>> and the user assumption "I have all the submodules" is true after
>> any "submodule update".
>>
>> By that point of view, we would not need to keep all submodules
>> initialized,
>> but only those the user is interested in. No need to have complicated
>> branch switching rules, but just as now "plus some futureproof rules
>> to declare my interest of submodules".
>
>
> I'm not sure what "complicated branch switching rules" you are
> referring to here, as far as I can see these only happen when we do
> not automatically initialize all submodules. What am I missing?
I was assuming we need to delete the submodules and preserve
their state somewhere.
So what I understand now:
$ git checkout <anotherbranch> # will not touch submodules, however
$ git submodule update # may update a different selection as the
$ # selection changed by a different .gitmodules file
>
> You'd have to deal with initialized but not to be updated submodules
> anyway (due to the user choosing a different label or upstream
> changing label assigments). So it looks to me like the approach to
> initialize them all as soon as they appear is easier to grok. And
> update, diff and status will just skip all submodules that don't
> match the configured label(s).
We can teach update, diff and status to ignore those non selected
submodules just fine, but I still think it is somewhat ugly.
(Consider the build system, which now needs to somehow know
which submodules to build. The non selected modules may
error out when building as their dependencies are wrong/not met;
also humans don't like wading through a ton of empty directories
to find their pet project)
>
> Additionally this will make it easier to e.g. change the upstream
> URL of the submodules in one go, as this has to be done after they
> have been initialized. If you clone the android repo from a local
> mirror it'd be great to just update all URL settings once right
> after clone instead of having to do that again each time you choose
> a different group.
>
> So I'm not per se against a lazy submodule init like you seem to
> propose it, but I believe it'd be better to just init them all as
> soon as they appear.
ok, I'll prepare a patch series for that.
>>> Yes. But I hope my arguments will convince you ;-)
>>
>>
>> --autoupdate-submodule seems to be one step ahead of my current
>> understanding?
>
>
> Yes, sorry for the confusion.
So now is time to start bikeshedding (aka naming things) again ;)
The main feature I'd understand is to only apply submodule update, diff, status
(and maybe more) to the selected submodules. So maybe
$ git clone --apply-actions-to-label <label/path/name pattern>
[may be repeated]
$ git submodule update # no additional arguments
$ git submodule add --label <label name>
In the .gitmodules file we can still have "submodule.$foo.label" but in the
.git/config we may want to have "submodule.action-on-label" instead ?
Thanks,
Stefan
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html