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

[Max Kirillov <max@max630.net>]

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. For example, the full git
repository takes about 70mb, and if I put master to
alternate store, the rest takes 7mb, and even if I clone all
original repository, debian repository and msysgit
repository, thay all take 15mb. It's without worktree, which
takes 27mb :)

-- 
Max