[prev in list] [next in list] [prev in thread] [next in thread]
List: git
Subject: Re: [PATCH v2 1/3] t: fix quotes tests for --pathspec-from-file
From: Alexandr Miloslavskiy <alexandr.miloslavskiy () syntevo ! com>
Date: 2019-12-31 10:01:47
Message-ID: 17de8859-10c2-b3e0-df5d-bf6d2681a528 () syntevo ! com
[Download RAW message or body]
Luckily, trailing \n didn't matter much, and I could also send input via
commandline argument instead of stdin, so here-doc is really the most
readable solution here.
Fixed it in V3, thanks for your suggestion!
On 30.12.2019 22:55, Eric Sunshine wrote:
> So, you want git-checkout to receive the following, quotes, backslash,
> and no newline, on its standard input?
>
> "file\101.t"
>
> If so, another way to achieve the same without taxing the brain of the
> reader or the next person who works on this code would be:
>
> tr -d "\012" | git checkout --pathspec-from-file=- HEAD^1 <<-\EOF &&
> "file\101.t"
> EOF
>
> Although it's three lines long, the body of the here-doc is the
> literal text you want sent to the Git command, so no counting
> backslashes, and no need for a lengthy in-code comment.
>
> But is the "no newline" bit indeed intentional? If not, then a simple
> echo would be even easier (though with a bit more escaping):
>
> echo "\"file\101.t\"" | git checkout --pathspec-from-file=-
HEAD^1 &&
>
On 31.12.2019 1:26, Jonathan Nieder wrote:
>> But is the "no newline" bit indeed intentional? If not, then a simple
>> echo would be even easier (though with a bit more escaping):
>>
>> echo "\"file\101.t\"" | git checkout --pathspec-from-file=- HEAD^1 &&
>
> For portability, that would be
>
> printf "%s\n" "\"file\101.t\"" | ...
>
> because some implementations of echo interpret escapes by default.
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic