Re: [PATCHv2 0/2] Submodule shallow recommendation [WAS: Submodules: have a depth field in the .gitmodules file]

From: Junio C Hamano <gitster@pobox.com>
Date: May 26, 2016, 18:13 UTC
Message-ID: <xmqq1t4owuue.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20160526000633.27223-1-sbeller@google.com>

Stefan Beller <sbeller@google.com> writes:

> Sometimes the history of a submodule is not considered important by
> the projects upstream. To make it easier for downstream users, allow
> a field 'submodule.<name>.depth' in .gitmodules, which can be used
> to indicate the recommended depth.

I have a design-level question.

If your project consists of 600 submodules, among which 40 of them you would recommend making a shallow clone, are there traits, other than "most people would not care about its history", that are shared across these 40 subprojects?

What I am trying to get at is that after adding .shallow annotation to these 40 submodules in .gitmodules, the project may need to add a different annotation for the same 40 submodules to control another operation. Which would be cumbersome, and a level of redirection might be a good way to solve it.

IIRC, earlier you had talked about a vision where you can just say 'submodule init --group=framework' to prepare your top-level project tree with its submodules in a state suitable to work on 'the framework part of the project', and the 'app' folks can substitute 'framework' with 'app' in that command. I thought the earlier defaultGroup work (and the attribute limited pathspec work that lays groundwork for it) was part of that effort.

Perhaps when a user says "submodule init --group=framework", that "framework" can choose some "developer profile" that indirectly specifies things like which group of submodules to initialize, which group of submodules can be shallow, etc.?

Just a strawman (without worrying about details and expressiveness of the syntax), I am wondering if you want something like this in your .gitmodules:

    [profile "framework"]
	initialize = $submodule_spec
        shallow = $submodule_spec
        ...

    [submodule "kernel"]
    	url = ...
        path = ...

...

where $submodule_spec would be a way to choose modules by various means. You may name them by their names. You may name them by their paths. With the submodule-pathspec topic graduated, you may use ":(attr:framework)*" to choose them by attribute limited pathspec.