Re: [PATCH 3/3] fetch: Use the remote's ref name to decide how to describe new refs.
- From
Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
- Date
- Apr 17, 2012, 08:39 UTC
- Message-ID
- <4F8D2C50.3060502@in.waw.pl>
- In-Reply-To
- <20120417075740.GE20017@burratino>
On 04/17/2012 09:57 AM, Jonathan Nieder wrote:
Show 18 quoted lines
> 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:
Show 6 quoted lines
> - 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