Re: [PATCH 3/3] fetch: Use the remote's ref name to decide how to describe new refs.

From: Marc Branchaud <marcnarc@xiplink.com>
Date: Apr 17, 2012, 14:23 UTC
Message-ID: <4F8D7CD5.3080508@xiplink.com>
In-Reply-To: <4F8D2195.9030507@in.waw.pl>

On 12-04-17 03:53 AM, Zbigniew Jędrzejewski-Szmek wrote:

Show 16 quoted lines

> On 04/17/2012 12:34 AM, Jonathan Nieder wrote:
>> marcnarc@xiplink.com wrote:
>>
>>> +        grep descriptive-branch actual | grep "[new branch]"&&
>>> +        grep descriptive-tag actual | grep "[new tag]"&&
>>> +        grep others/crazy actual | grep "[new ref]"
>>
>> Careful. :)  I suppose the simplest fix would be to leave out the
>> brackets so the '[new ref]' tag is not misinterpreted as a character
>> class, like so:
>>
>>     grep "new branch.*descriptive-branch" actual&&
>>     grep "new tag.*descriptive-tag" actual&&
>>     grep "new ref.*others/crazy" actual
> 
> s/grep/test_i18ngrep/

With the switch to test_i18ngrep do I have to worry about possible regexp misinterpretations of "[new branch]" et al?

Jonathan, I figured regexps aren't an issue with plain "grep" (unlike "egrep" or "grep -e"). I take it this is a portability concern -- are there systems that actually replace plain "grep" like a "egrep"?

Also, in my test's pipes I believe only the second "grep" needs to be "test_i18ngrep", right? (Only strings like "[new branch]" are internationalized.)

Show 10 quoted lines

> Also:
>>> +    echo "Nuts" >> crazy &&
>>> +    git add crazy &&
>>> +    git commit -a -m "descriptive commit" &&
>>> +    git update-ref refs/others/crazy HEAD &&
>>> +    (
>>> +        cd descriptive &&
>>> +        git fetch o 2> actual
> redirections should be without spaces between '>' and the filename
> (>>crazy, 2>actual), for portability.

Consistency; got it.

Thanks guys!

M.