From: Duy Nguyen <pclouds@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Stefan Beller <sbeller@google.com>,
Git Mailing List <git@vger.kernel.org>,
Jonathan Nieder <jrnieder@gmail.com>,
Jens Lehmann <Jens.Lehmann@web.de>
Subject: Re: [RFC PATCH 0/4] pathspec labels [WAS: submodule groups]
Date: Mon, 16 May 2016 07:03:50 +0700 [thread overview]
Message-ID: <CACsJy8BU-zym6Nkmbs-jk66af1LwHaasybHBvBUJscU=eBOkQA@mail.gmail.com> (raw)
In-Reply-To: <xmqqfutj5d73.fsf@gitster.mtv.corp.google.com>
On Mon, May 16, 2016 at 2:33 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Duy Nguyen <pclouds@gmail.com> writes:
>>
>>> Instead of putting everything in under the same attribute name
>>> "label", make one attribute per label? Would this work?
>>>
>>> *.[ch] c-group code-group
>>
>> The attribute subsystem expects that there will not be unbounded
>> large number of attributes, so this is not a good direction to go.
>
> Having said that, I do not mind too much if it turns out that it is
> necessary to use an unbounded set of random attributes to solve a
> specific problem, if the use case is good.
I only have a vague idea so far, it seems to me a good idea to be able
to specify "binary-marked paths" or "filter attached paths" from
pathspec. We can already do this with scripts, but we need to be very
careful about quoting. And if it's pathspec it can be combined with
other magic (most likely negation)
> But even then, in order to avoid confusion and name clashes, I'd
> prefer to see more like
>
> *.[ch] group-c group-code
>
> that is matched by
>
> git cmd ':(group:c code)
>
> i.e. reserve a single prefix that is not and will not be used for
> other purposes.
For my above use case, i can still define macro group-binary that is
an alias of binary to get around this. So it's ok.
--
Duy
next prev parent reply other threads:[~2016-05-16 0:04 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-13 0:19 [RFC PATCH 0/4] pathspec labels [WAS: submodule groups] Stefan Beller
2016-05-13 0:19 ` [PATCH 1/4] Documentation: correct typo in example for querying attributes Stefan Beller
2016-05-13 0:19 ` [PATCH 2/4] pathspec: move long magic parsing out of prefix_pathspec Stefan Beller
2016-05-13 0:19 ` [PATCH 3/4] pathspec: move prefix check out of the inner loop Stefan Beller
2016-05-13 4:43 ` Junio C Hamano
2016-05-13 0:19 ` [PATCH 4/4] pathspec: record labels Stefan Beller
2016-05-13 4:32 ` Junio C Hamano
2016-05-13 5:26 ` Stefan Beller
2016-05-13 5:26 ` Junio C Hamano
2016-05-13 5:41 ` Stefan Beller
2016-05-13 6:28 ` Junio C Hamano
2016-05-15 10:06 ` [RFC PATCH 0/4] pathspec labels [WAS: submodule groups] Duy Nguyen
2016-05-15 18:19 ` Junio C Hamano
2016-05-15 19:33 ` Junio C Hamano
2016-05-16 0:03 ` Duy Nguyen [this message]
2016-05-16 17:20 ` Stefan Beller
2016-05-16 17:39 ` Junio C Hamano
2016-05-16 17:48 ` Stefan Beller
2016-05-16 21:18 ` Junio C Hamano
2016-05-16 21:36 ` Stefan Beller
2016-05-16 21:50 ` Junio C Hamano
2016-05-16 22:00 ` Stefan Beller
2016-05-16 22:02 ` Junio C Hamano
2016-05-16 22:09 ` Stefan Beller
2016-05-16 22:19 ` 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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CACsJy8BU-zym6Nkmbs-jk66af1LwHaasybHBvBUJscU=eBOkQA@mail.gmail.com' \
--to=pclouds@gmail.com \
--cc=Jens.Lehmann@web.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jrnieder@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.
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 NNTP newsgroup(s).