Stefan Beller <sbel...@google.com> writes:
> On Thu, May 26, 2016 at 11:13 AM, Junio C Hamano <gits...@pobox.com> wrote:
>> Stefan Beller <sbel...@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?
>
> From my understanding these 40 subprojects are a large file storage
> done different than Git LFS. In the repo world this was choosen to be
> a separate repository, such that you had versioning available as the
> large files change a few times (like a precompiled kernel for special
> hardware, etc). And this is one of the missing pieces to translate the
> current repo-tool workflow to submodules.
I am not questioning the value of being able to say "this and that
submodule need only a shallow copy". I am trying to see
"individually mark each and every such submodules" should be the
primary interface to do so.
> So you are proposing another layer of indirection, i.e. instead of giving
> a pathspec with ":(attr:label-framework)" we would want to give a profile
> which then has the pathspec plus additional information on shallowness
> an such.
I do not understand what you mean by "instead of giving a pathspec"
at all.
When you have 40 submodules, with your design the user has to
sprinkle 40 lines of
shallow = true
for each of [submodule "$n"] sections. If there are other traits
(see my first question) that are similar, they will have some other
setting next to the "shallow = true" 40 times. When a new submodule
is added to that same class, they will again have to add these two
lines.
I was wondering if a level of indirection that lets you say
"submodules in this group all share 'shallow=true' (by default)"
would improve that cumbersomeness. When you add another similar
trait, you add that just once, not 40 times. When you add another
submodule, you say "this submodule is also in that group", without
mentioning "shallow".
We probably _need_ shallow=true at individual module level, if only
to override the default given by such an indirection scheme. So
don't take the message you are responding to as "no, your design is
not good, scrap it, and here is a better one". It is more like "It
would be a good first step, but have you considered where it will
eventually lead us to? Would the more complete future look like
this, and how well would this first step fit in that world? Would
it be a good escape hatch, or would it have to be deprecated?"
> And you reinvented submodule groups. ;)
> IIRC we had a discussion if we want to have the submodule groups
> stored at each submodule or at a central "profile/group" setting.
As I said, it was not my intention to get into that; I am not
interested in the exact syntax, and I am not interested whether the
pointer goes from group to individual modules (i.e. [group "bar"]
says "foo" is one of its member modules), or individual modules have
pointers to groups (i.e. "module [foo]" declares its membership in
group "bar") at all. I really do not care.
What matters in my suggestion was, after you established that group
"bar" exists, you can do:
[profile "framework"]
shallow = "some notation that refers to group bar"
so that you do not have to repeat "shallow = true" many times per
submodule.
By the way, I do not see the "profile" as about "submodules" or
"submodule groups". It is more about "Who am I? What am I working
on? Give me an appropriate set of settings for the 600 submodules
you have, with the knowledge that I am a framework person".
grouping submodules would merely be one mechanism to help specify
that.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
