Re: [PATCH 0/7] submodule groups

From: Stefan Beller <sbeller@google.com>
Date: May 11, 2016, 23:07 UTC
Message-ID: <CAGZ79kY3S6SmJOMQ7RAKw0yTvicY=Y1VRRGdm5uK9+Eb7W+Ykg@mail.gmail.com>
In-Reply-To: <xmqq4ma5l526.fsf@gitster.mtv.corp.google.com>

On Tue, May 10, 2016 at 7:08 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 8 quoted lines

> Stefan Beller <sbeller@google.com> writes:
>
>> I started from scratch as I think there were some sharp edges in the design.
>> My thinking shifted from "submodule groups" towards "actually it's just an
>> enhanced pathspec, called submodulespec".
>
> Except for minor things I mentioned separately, overall, this seems
> quite cleanly done.

I disagree (now).

I started documenting the <submodulespec> as an extension of the pathspecs. While I thought the logical OR was the right way to go, I think it is wrong now. So there is stuff in tests like:

    git submodule--helper matches-submodulespec sub0 ./.
./:(exclude)*0 *label-sub0

which should test if the first argument (sub0) matches the submodulespec which follows. And it matches sub0 by matching the label, although we told it to ignore anything ending in 0

So I wonder if we rather want to extend the pathspec magic to include properties of blobs (i.e. submodules):

    git <command> . :(sub-label:label-sub0) :(exclude)*0

would look much more powerful too me. Properties of blobs may also be interesting for otherwise. Imagine looking for huge files (in a bare repo, so you have to use Git and not your shell tools):

  git ls-files . :(file-size:>1024k)

>
> Looks very promising.
>

Thanks for the encouragement!

Thanks, Stefan