Stefan Beller writes:
> 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`)
Yes, my idle speculation between "[submodule"x"] label=A" stored
in .gitmodules and "path
On Thu, May 12, 2016 at 8:58 AM, Junio C Hamano wrote:
> Junio C Hamano 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
>> th
Junio C Hamano 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 i
On Wed, May 11, 2016 at 10:50 PM, Junio C Hamano wrote:
>
> git cmd -- \*.perl \*.pl \*.pm
>
> I've often wondered if it would be a good idea to let attributes
> file to specify "these paths form the group Perl" with something
> like:
>
> *.pmgroup=perl
> *.plgroup=perl
Stefan Beller writes:
> If you have lots of submodules, you probably don't need all of them at once,
> but you have functional units. Some submodules are absolutely required,
> some are optional and only for very specific purposes.
>
> This patch series adds labels to submodules in the .gitmodule
Junio C Hamano writes:
> I'd suggest not to over-engineer this. Go back and imagine how
> "/bin/ls" would work is a good sanity check to gauge what complexity
> levels ordinary users would feel comfortable to handle.
>
> "ls a b" would give union of what "ls a" and "ls b" would output,
> there i
Stefan Beller writes:
> git submodule--helper matches-submodulespec sub0 ./.
> ./:(exclude)*0 *label-sub0
>
> which should test if the first argument (sub0) matches the submodulespec
> which follows.
This, according to that "OR'ed together" definition, asks to find a
submodule
- whose p
On Wed, May 11, 2016 at 4:48 PM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>>> git ls-files . :(file-size:>1024k)
>>
>> I somehow do not think this is a way normal people (read: end users)
>> would want to interact with Git. Pathspec is about "paths" and
>> various ways to match them.
Junio C Hamano writes:
>> git ls-files . :(file-size:>1024k)
>
> I somehow do not think this is a way normal people (read: end users)
> would want to interact with Git. Pathspec is about "paths" and
> various ways to match them. It is not about contents that happens
> to be currently named by
Stefan Beller writes:
> So I wonder if we rather want to extend the pathspec magic to
> include properties of blobs (i.e. submodules):
>
> git . :(sub-label:label-sub0) :(exclude)*0
>
> would look much more powerful too me. Properties of blobs
> may also be interesting for otherwise. Imagine
On Tue, May 10, 2016 at 7:08 PM, Junio C Hamano wrote:
> Stefan Beller 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 fo
Stefan Beller 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
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".
The meat is found in the last 3 patches.
What is this series about?
==
If you
13 matches
Mail list logo
