git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 0/7] submodule groups

From
Stefan Beller <sbeller@google.com>
Date
May 12, 2016, 16:35 UTC
Message-ID
<CAGZ79kZHbAiP13rC+VLnFUtoxPZEcyx_wkrxfKb+cGBxQaojZQ@mail.gmail.com>
In-Reply-To
<xmqqoa8bgten.fsf@gitster.mtv.corp.google.com>
On Thu, May 12, 2016 at 8:58 AM, Junio C Hamano <gitster@pobox.com> wrote:
Show 43 quoted lines
> Junio C Hamano <gitster@pobox.com> writes:
>
>> The reason why I suspect that this may not work well with submodule
>> labels is because submodule labels (or any attribute we give via
>> .gitmodules to a submodule) are keyed by a submodule name, which is
>> the primary unchanging key (so that people can "mv" a submodule in
>> the context of the toplevel superproject without losing track of
>> submodule identity), not by paths to submodules, while the "group"
>> thing I want is merely a short-hand for pathspec elements and wants
>> to be keyed by paths.
>>
>> But there may be somebody more clever than I who can come up with a
>> way to unify these two similar concepts without confusing end users.
>
> Thinking about this even more, if there is no requirement that
> labels must be tied to submodule names, we just can scrap the idea
> of "submodule labels" to group things and instead just use "path
> labels", i.e. write the full path to the submodule and assign it a
> label in .gitattributes and use it in place of where we used *label
> in the patch series.  After all, an easy way to choose some among
> many submodules logically is a subset of an easy way to choose some
> among many paths.
>
> The only reason why we added the submodule label to .gitmodules is
> because we viewed it as submodule-specific thing and the "keyed by
> name, not path" came as a consequence, not because any real "we must
> key it by name because..." reason, I would think.
>
> I know this is a huge departure from the design presented both at
> the conceptual level and also at the implementation level, and that
> is one of the reasons why I do not particularly want to like it, but
> on the other hand, I am not bold enough to say that I will have a
> good answer when later somebody asks "Why can we group only
> submodules with labels, but not random group of paths (e.g. 'these
> directories are about documentation')?"  And then, if we add path
> labels to allow expressing groups of paths later, the follow-up
> question would be "When should I use submodule labels and when
> should I use path labels?  I can use path labels to group submodules
> and say 'git submodule update -- :(group=docs)' can't I?".
>
> And that makes me pause and step back from the "submodule labels"
> idea.
>

It sounds better at first (and I haven't thought further). So if we were to go with this idea:

Label paths (or even pathspecs?) in the .gitattributes file.

I think it is important to keep the property of defining the labeling in the tree, so you can follow upstream easier.

I tried coming up with an example for labels for generic paths, but it looks like most of the time it is a substitution for a pathspec, I did not find a convincing example which makes it easier to use.

`:(group=docs)` in the non submodule case could be expressed as `Documentation/**`. Well maybe we also want to include README and some other files which need to stay outside the Documentation directory, so I can see how it may be useful.

We do not need a special labeling command. We do not ship with a command which writes the .gitattributes or .gitignore for you, and labels don't require this. So I could drop the patch for "submodule add --label".

We can still keep the submodule.defaultGroup. (In the WIP I renamed it to updateGroup as its only feature is to have it set during clone and remebered for `git submodule update`)

When we allow labels to be generic path labels instead of submodule labels, the user might be tempted to ask, why the submodules can be specified but not the individual paths, i.e.

    git clone --init-submodule="(:group=docs)" ...
may strongly hint at:
    git clone --narrow="(:group=docs)" ...
would only get parts of the repository.

For the submodule case, this may add confusion as the user would need to configure some properties in the .gitmodules file and some in the .gitattributes file.

I think I'll try implementing a mock and see how much code it is for a more fundamental pathspec extension.

Thanks, Stefan

Previous: Junio C HamanoNext: Junio C Hamano
Message 29 of 30 in “submodule groups”
  1. 0/7 submodule groupsStefan Beller, May 11, 2016
  2. 1/7 submodule--helper: add valid-label-nameStefan Beller, May 11, 2016
  3. Junio C HamanoMay 11, 2016
  4. 2/7 submodule add: label submodules if asked toStefan Beller, May 11, 2016
  5. Junio C HamanoMay 11, 2016
  6. Stefan BellerMay 11, 2016
  7. 3/7 submodule-config: keep labels aroundStefan Beller, May 11, 2016
  8. Junio C HamanoMay 11, 2016
  9. Stefan BellerMay 11, 2016
  10. Junio C HamanoMay 11, 2016
  11. Stefan BellerMay 11, 2016
  12. 4/7 submodule-config: check if a submodule is in a groupStefan Beller, May 11, 2016
  13. Junio C HamanoMay 11, 2016
  14. 5/7 submodule--helper module_list_compute: allow label or name argumentsStefan Beller, May 11, 2016
  15. Junio C HamanoMay 11, 2016
  16. Junio C HamanoMay 11, 2016
  17. 6/7 submodule update: learn partial initializationStefan Beller, May 11, 2016
  18. 7/7 clone: allow specification of submodules to be clonedStefan Beller, May 11, 2016
  19. Junio C HamanoMay 11, 2016
  20. Stefan BellerMay 11, 2016
  21. Junio C HamanoMay 11, 2016
  22. Junio C HamanoMay 11, 2016
  23. Stefan BellerMay 11, 2016
  24. Junio C HamanoMay 12, 2016
  25. Junio C HamanoMay 12, 2016
  26. Junio C HamanoMay 12, 2016
  27. Stefan BellerMay 12, 2016
  28. Junio C HamanoMay 12, 2016
  29. Stefan BellerMay 12, 2016
  30. Junio C HamanoMay 12, 2016

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.