Re: [PATCH/RFC v2] Squashed changes for multiple worktrees vs. submodules

[Jens Lehmann <Jens.Lehmann@web.de>]

Am 07.12.2014 um 07:42 schrieb Max Kirillov:
> On Sat, Dec 06, 2014 at 02:06:08PM +0100, Jens Lehmann wrote:
>> Am 05.12.2014 um 07:32 schrieb Max Kirillov:
>>> Currently I'm estimating approach when submodules which have .git
>>> file or directory inside are updated, and those which do not have it are not.
>>> I have added a config variable submodule.updateIgnoringConfigUrl (because
>>> usually the submodule.<name>.url is what turns on the update). It looks working,
>>> maybe I even add setting the variable when chackout --to is used.
>
>> But it's not only submodule.<name>.url, the list goes on with
>> update, fetch & ignore and then there are the global options
>> like diff.submodule, diff.ignoreSubmodules and some more.
>
> I believe that parameters are important for some use, but I
> know several tesns of git users who have no idea bout them,
> and I myself only learned about them while working on this.

But we still want to support them all properly, no?

> To have some a submodule not initialized in some sorktree is
> what I really need. I was sure before it is managed by
> having the submodule checked out. Probably I just did not
> run `submodule update` in the worktree where did not use
> submodules, but I cannot rely on it.  I see now from
> 211b7f19c7 that adding parameter for all updates will break
> the initalization. Maybe it would be better to have a
> runtime argument: `git submodule update --ignore-config-url`

Huh? I think we already have that: If you ignore the url
config it's as if the submodule was never initialized, so
you can just *not* run the "git submodule update" command
at all to get that effect. No new option needed ;-)

>> Thanks to you and Duy for discussing this with me! I'd sum it
>> up like this:
>>
>> *) Multiple worktrees are meant to couple separate worktrees
>>     with a single repository to avoid having to push and fetch
>>     each time to sync refs and also to not having to sync
>>     settings manually (with the benefit of some disk space
>>     savings). That's a cool feature and explains why a branch
>>     should be protected against being modified in different
>>     worktrees.
>
> I should notify that I am not the author of the feature,
> maybe Duy have some other vision.
>
>>     The first level submodule settings are shared between the
>>     multiple worktrees; submodule objects, settings and refs
>>     aren't (because the .git/modules directory isn't shared).
>>
>>     Looks like that would work with just what we have now, no?
>
> Yes, very much like what I proposed in $gmane/258173, but I
> need to have something about preventing checkout. And I
> should review what I've done since that, maybe there are
> more things to fix.

Hmm, I do not get the "preventing checkout" part. If you ran
"git submodule init <path>" in just one of the multiple work
trees a later "git submodule update" in any of the multiple
work trees will checkout the submodule there. The only way I
can imagine to change that is to implement separate worktree
configurations for each of the multiple worktrees.

>> *) I'd love to see a solution for sharing the object database
>>     between otherwise unrelated clones of the same project (so
>>     that fetching in one clone updates the objects in the common
>>     dir and gc cannot throw anything away used by one of the
>>     clones). But I'd expect a bare repository as the common one
>>     where we put the worktrees refs into their own namespaces.
>
> There is a GIT_NAMESPACE already, maybe it should be just
> extended to work with all commands?

As you already noticed, it isn't a solution for my problem.

> btw, have you tried alternates? It does reduce the number of
> objects you need to keep very strongly. You can put in the
> alternate store only released branches which are guaranteed
> to be not force-updated, to avoid issues with missing
> objects, and it still helps.

Which is exactly what we do *not* want to do on a CI server,
its purpose is to endlessly build development branches that
are force-updated on a regular basis.