On Tue, Aug 27, 2013 at 12:07 AM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> Not necessarily. If the user is asking the question in a more
>> natural way (I want to see where in 'next' branch's tip commit hits
>> appear, by the way, I know I am only interested in builtin/ so I'd
>> give
Junio C Hamano writes:
> Not necessarily. If the user is asking the question in a more
> natural way (I want to see where in 'next' branch's tip commit hits
> appear, by the way, I know I am only interested in builtin/ so I'd
> give pathspec as well when I am asking this question), the output
>
On Mon, Aug 26, 2013 at 1:26 PM, Junio C Hamano wrote:
> Phil Hord writes:
>
>>> If your justification were "above says 'there may be a readon why
>>> the user wanted to ask it in that way', i.e. 'find in this tree
>>> object HEAD:some/path and report where hits appear', but the reason
>>> can on
Phil Hord writes:
>> If your justification were "above says 'there may be a readon why
>> the user wanted to ask it in that way', i.e. 'find in this tree
>> object HEAD:some/path and report where hits appear', but the reason
>> can only be from laziness and/or broken script and the user always
>>
On Mon, Aug 26, 2013 at 1:03 PM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> If your justification were "above says 'there may be a readon why
>> the user wanted to ask it in that way', i.e. 'find in this tree
>> object HEAD:some/path and report where hits appear', but the reason
>> can o
On Mon, Aug 26, 2013 at 12:49 PM, Phil Hord wrote:
> If so, then I would like to point out to you the convenience I
> accidentally encountered using this tool. Perhaps you didn't realize
> how helpful it was when you chose to use a colon there.
My itch comes from a case where I am looking for re
Junio C Hamano writes:
> If your justification were "above says 'there may be a readon why
> the user wanted to ask it in that way', i.e. 'find in this tree
> object HEAD:some/path and report where hits appear', but the reason
> can only be from laziness and/or broken script and the user always
>
On Mon, Aug 26, 2013 at 12:23 PM, Junio C Hamano wrote:
> Phil Hord writes:
>
>> On Mon, Aug 26, 2013 at 3:14 AM, Junio C Hamano wrote:
>>> Junio C Hamano writes:
>>>
Jonathan Nieder writes:
> I think Phil meant that when "git grep" is asked to search within
> "HEAD:some/path
Phil Hord writes:
> On Mon, Aug 26, 2013 at 3:14 AM, Junio C Hamano wrote:
>> Junio C Hamano writes:
>>
>>> Jonathan Nieder writes:
>>>
I think Phil meant that when "git grep" is asked to search within
"HEAD:some/path", filenames tacked on at the end should be appended
with a '/
On Mon, Aug 26, 2013 at 3:14 AM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> Jonathan Nieder writes:
>>
>>> I think Phil meant that when "git grep" is asked to search within
>>> "HEAD:some/path", filenames tacked on at the end should be appended
>>> with a '/' separator instead of the us
Junio C Hamano writes:
> Jonathan Nieder writes:
>
>> I think Phil meant that when "git grep" is asked to search within
>> "HEAD:some/path", filenames tacked on at the end should be appended
>> with a '/' separator instead of the usual ':' (e.g.,
>> "HEAD:some/path/inner/path.c", not "HEAD:some/
On Sat, Aug 24, 2013 at 10:41:42PM -0700, Jonathan Nieder wrote:
> Jeff King wrote:
>
> > So we are necessarily reconstructing based on what we know of the
> > syntax. And I think that your rule is OK, because we know that refnames
> > cannot contain a colon.
>
> What happens with expressions li
Jeff King wrote:
> So we are necessarily reconstructing based on what we know of the
> syntax. And I think that your rule is OK, because we know that refnames
> cannot contain a colon.
What happens with expressions like HEAD^{/test:}?
Jonathan
--
To unsubscribe from this list: send the line "uns
Jonathan Nieder writes:
> I think Phil meant that when "git grep" is asked to search within
> "HEAD:some/path", filenames tacked on at the end should be appended
> with a '/' separator instead of the usual ':' (e.g.,
> "HEAD:some/path/inner/path.c", not "HEAD:some/path:inner/path.c").
Ah, OK.
I
On Sat, Aug 24, 2013 at 09:35:58PM -0400, Phil Hord wrote:
> When the pathspec given to grep includes a tree name, the full
> name of matched files is assembled using colon as a separator.
> If the pathspec includes a tree name, it should use a slash
> instead.
>
> Check if the pathspec already n
Junio C Hamano wrote:
> Phil Hord writes:
>> On Sat, Aug 24, 2013 at 9:35 PM, Phil Hord wrote:
>>> When the pathspec given to grep includes a tree name, the full
>>> name of matched files is assembled using colon as a separator.
>>> If the pathspec includes a tree name, it should use a slash
>>>
Phil Hord writes:
> On Sat, Aug 24, 2013 at 9:35 PM, Phil Hord wrote:
>>
>> When the pathspec given to grep includes a tree name, the full
>> name of matched files is assembled using colon as a separator.
>> If the pathspec includes a tree name, it should use a slash
>> instead.
>>
>> Check if t
On Sat, Aug 24, 2013 at 9:35 PM, Phil Hord wrote:
>
> When the pathspec given to grep includes a tree name, the full
> name of matched files is assembled using colon as a separator.
> If the pathspec includes a tree name, it should use a slash
> instead.
>
> Check if the pathspec already names a t
When the pathspec given to grep includes a tree name, the full
name of matched files is assembled using colon as a separator.
If the pathspec includes a tree name, it should use a slash
instead.
Check if the pathspec already names a tree and ref (including
a colon) and use a slash if so.
---
I'm
19 matches
Mail list logo
