git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Stefan Beller <sbeller@google.com>
Cc: jrnieder@gmail.com, Jens.Lehmann@web.de, git@vger.kernel.org,
	pclouds@gmail.com
Subject: Re: [PATCH 0/7] submodule groups
Date: Thu, 12 May 2016 08:58:24 -0700	[thread overview]
Message-ID: <xmqqoa8bgten.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <xmqq37pnj04f.fsf@gitster.mtv.corp.google.com> (Junio C. Hamano's message of "Wed, 11 May 2016 22:50:24 -0700")

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.

  parent reply	other threads:[~2016-05-12 15:58 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-11  0:59 [PATCH 0/7] submodule groups Stefan Beller
2016-05-11  0:59 ` [PATCH 1/7] submodule--helper: add valid-label-name Stefan Beller
2016-05-11  1:11   ` Junio C Hamano
2016-05-11  0:59 ` [PATCH 2/7] submodule add: label submodules if asked to Stefan Beller
2016-05-11  1:13   ` Junio C Hamano
2016-05-11 17:26     ` Stefan Beller
2016-05-11  0:59 ` [PATCH 3/7] submodule-config: keep labels around Stefan Beller
2016-05-11  1:15   ` Junio C Hamano
2016-05-11 17:41     ` Stefan Beller
2016-05-11 21:28       ` Junio C Hamano
2016-05-11 21:39         ` Stefan Beller
2016-05-11  0:59 ` [PATCH 4/7] submodule-config: check if a submodule is in a group Stefan Beller
2016-05-11  1:19   ` Junio C Hamano
2016-05-11  0:59 ` [PATCH 5/7] submodule--helper module_list_compute: allow label or name arguments Stefan Beller
2016-05-11  1:29   ` Junio C Hamano
2016-05-11  2:24     ` Junio C Hamano
2016-05-11  0:59 ` [PATCH 6/7] submodule update: learn partial initialization Stefan Beller
2016-05-11  0:59 ` [PATCH 7/7] clone: allow specification of submodules to be cloned Stefan Beller
2016-05-11  2:08 ` [PATCH 0/7] submodule groups Junio C Hamano
2016-05-11 23:07   ` Stefan Beller
2016-05-11 23:39     ` Junio C Hamano
2016-05-11 23:48       ` Junio C Hamano
2016-05-11 23:57         ` Stefan Beller
2016-05-12  0:00     ` Junio C Hamano
2016-05-12  4:33       ` Junio C Hamano
2016-05-12  5:50 ` Junio C Hamano
2016-05-12 15:32   ` Stefan Beller
2016-05-12 15:58   ` Junio C Hamano [this message]
2016-05-12 16:35     ` Stefan Beller
2016-05-12 16:53       ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqoa8bgten.fsf@gitster.mtv.corp.google.com \
    --to=gitster@pobox.com \
    --cc=Jens.Lehmann@web.de \
    --cc=git@vger.kernel.org \
    --cc=jrnieder@gmail.com \
    --cc=pclouds@gmail.com \
    --cc=sbeller@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).