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

> 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.

> 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`

>> 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.

>> *) 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?

> 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.