public inbox for git@vger.kernel.org 
 help / color / mirror / Atom feed
From: Ramsay Jones <ramsay@ramsayjones•plus.com>
To: Junio C Hamano <gitster@pobox•com>
Cc: Stefan Beller <sbeller@google•com>,
	pclouds@gmail•com, git@vger•kernel.org
Subject: Re: [RFC/PATCH] pathspec: allow escaped query values
Date: Thu, 2 Jun 2016 16:30:13 +0100	[thread overview]
Message-ID: <57505105.2000801@ramsayjones.plus.com> (raw)
In-Reply-To: <xmqqy46ouorn.fsf@gitster.mtv.corp.google.com>



On 02/06/16 06:46, Junio C Hamano wrote:
> Ramsay Jones <ramsay@ramsayjones•plus.com> writes:
> 
>> Not having given this much thought at all, but the question which comes
>> to mind is: can you use some other separator for the <attr>-s rather than
>> a comma? That way you don't need to quote them in the <value> part of the
>> <attr>-spec.
>>
>> (I dunno, maybe use ; or : instead?)
> 
> There are two kinds of comma involved in this discussion.
> 
>  * Multiple pathspec magic can be attached to augment the way
>    <pattern> selects paths. ":(<magic1>,<magic2>,...)<pattern>" is
>    the syntax, and <magicN> are things like "icase" (select the path
>    that matches <pattern> case-insensitively), "top" (<pattern> must
>    match from the top level of the working tree, even when you are
>    running the command from a subdirectory).  We added a new kind of
>    <magic> whose syntax is "attr:VAR=VAL" recently, which says "not
>    only <pattern> must match the path, in order to be selected, the
>    path must have the attribute VAR with value VAL".
> 
>    The comma that separates multiple magic is not something you can
>    change now; it has been with us since v1.7.6 (Jun 2011)
> 
>  * My example wanted to use the attr:VAR=VAL form to select those
>    paths that has one specific string as the value for whitespace
>    attribute, i.e. VAR in this case is "whitespace".  The value for
>    whitespace attribute determines what kind of whitespace anomalies
>    are considered as errors by "git apply" and "git diff", and it is
>    formed by concatenating things like "indent-with-non-tab" (starts
>    a line with more than 8 consecutive SPs), "space-before-tab" (a
>    SP appears immediately before HT in the indent), etc., with a
>    comma in between.
> 
>    The comma that separates various kinds of whitespace errors is
>    not something you can change now; it has been with us since
>    v1.5.4 (Feb 2008).
> 
> So using different separator is not a viable solution.

Ah, OK, makes sense. Note that I have not used 'pathspec magic' or
the attribute system in git (never felt/had the need)! ;-)

So, at risk of annoying you, let me continue in my ignorance a little
longer and ask: even if you have to protect all of this 'magic' from
the shell with '/" quoting, could you not use (nested) quotes to
protect the <value> part of an <attr>? For example:

    git ls-files ':(attr:whitespace="indent,trail,space",icase)'

[Hmm, I don't seem to be able to find documentation on the syntax
of these features (apart from the code, of course).]

ATB,
Ramsay Jones

  reply	other threads:[~2016-06-02 15:30 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-01 23:52 [RFC/PATCH] pathspec: allow escaped query values Stefan Beller
2016-06-02  0:33 ` Junio C Hamano
2016-06-02  2:23   ` Stefan Beller
2016-06-02  0:38 ` Ramsay Jones
2016-06-02  2:20   ` Stefan Beller
2016-06-02  5:46   ` Junio C Hamano
2016-06-02 15:30     ` Ramsay Jones [this message]
2016-06-02 16:10       ` Junio C Hamano
2016-06-02 18:42         ` Ramsay Jones
2016-06-02 18:58           ` Junio C Hamano
2016-06-02 19:29             ` Junio C Hamano
2016-06-02 19:52               ` Ramsay Jones
2016-06-02 19:04           ` Stefan Beller
2016-06-02 19:44             ` Ramsay Jones
2016-06-02 19:46               ` Junio C Hamano
2016-06-02 19:53                 ` Ramsay Jones

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=57505105.2000801@ramsayjones.plus.com \
    --to=ramsay@ramsayjones$(echo .)plus.com \
    --cc=git@vger$(echo .)kernel.org \
    --cc=gitster@pobox$(echo .)com \
    --cc=pclouds@gmail$(echo .)com \
    --cc=sbeller@google$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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