From: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
Date: Tue, 17 Apr 2012 08:39:44 GMT
Subject: Re: [PATCH 3/3] fetch: Use the remote's ref name to decide how to describe new refs.
Message-ID: <4F8D2C50.3060502@in.waw.pl>
In-Reply-To: <20120417075740.GE20017@burratino>

On 04/17/2012 09:57 AM, Jonathan Nieder wrote:
> Zbigniew Jędrzejewski-Szmek wrote:
>> On 04/17/2012 12:34 AM, Jonathan Nieder wrote:
>>> marcnarc@xiplink.com wrote:
>
>>>> +	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.
>
> I think you mean for consistency.  A space between the operator and
> filename is perfectly portable, though git's tests tend to use a
> style without the space.
Yes, you're right. I mixed up the motivation for two different rules...

Quoting Junio C Hamano:
>  - Strictly speaking, the target of I/O redirection (e.g. >"$name") does
>    not have to have quotes around it, but some versions of bash are known
>    to give misguided warnings against it;
>
>  - We do not write SP between the redirection and filename, but we do have
>    one SP before the redirection; and
So rule #2 is for consistency, rule #1 for portability.

-
Zbyszek