All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Torsten Bögershausen" <tboegi@web.de>
To: "Ramsay Jones" <ramsay@ramsayjones.plus.com>,
	"Torsten Bögershausen" <tboegi@web.de>,
	dev+git@drbeat.li, "Git Mailing List" <git@vger.kernel.org>
Subject: Re: t6023 broken under Mac OS
Date: Fri, 1 Jan 2016 23:23:46 +0100	[thread overview]
Message-ID: <5686FC72.8030008@web.de> (raw)
In-Reply-To: <5686EC29.3080901@ramsayjones.plus.com>

On 2016-01-01 22.14, Ramsay Jones wrote:
> 
> 
> On 01/01/16 17:49, Torsten Bögershausen wrote:
>> On 2016-01-01 18.14, Ramsay Jones wrote:
>>> Hi Torsten,
>>>
>>> On 01/01/16 15:36, Torsten Bögershausen wrote:
>>>> The (last) test case
>>>> 'conflict markers contain CRLF when core.eol=crlf'
>>>>
>>>> does not work as expected under Mac OS: "wc -l" is not portable and the line
>>>> test $(sed -n "/\.txt\r$/p" output.txt | wc -l) = 3
>>>> fails.
>>>
>>> Hmm, I have never used a Mac, so I'm just guessing here, but
>>> you could try something like (obviously untested!):
>>>
>>> diff --git a/t/t6023-merge-file.sh b/t/t6023-merge-file.sh
>>> index 245359a..68b306f 100755
>>> --- a/t/t6023-merge-file.sh
>>> +++ b/t/t6023-merge-file.sh
>>> @@ -350,7 +350,7 @@ test_expect_success 'conflict at EOF without LF resolved by --union' \
>>>  test_expect_success 'conflict markers contain CRLF when core.eol=crlf' '
>>>  	test_must_fail git -c core.eol=crlf merge-file -p \
>>>  		nolf-diff1.txt nolf-orig.txt nolf-diff2.txt >output.txt &&
>>> -	test $(sed -n "/\.txt\r$/p" output.txt | wc -l) = 3
>>> +	test $(tr "\015" Q <output.txt | sed -n "/\.txtQ$/p" | wc -l) -eq 3
>>>  '
>>>  
>>>  test_done
>> Yes, this works.
>>
>>>
>>> [The 'wc -l' portability should only be a problem if you rely on the
>>> exact textual form of the output, rather than the integer count.
>>> 'wc -l' is used in many many tests ...]
>>>
>>> Note that this test is not checking all conflict markers (the
>>> ======= marker does not have a filename appended). Should that
>>> be fixed also?
>> This is may attempt (against pu)
>>
>> diff --git a/t/t6023-merge-file.sh b/t/t6023-merge-file.sh
>> index 68b306f..b1f8e41 100755
>> --- a/t/t6023-merge-file.sh
>> +++ b/t/t6023-merge-file.sh
>> @@ -350,7 +350,13 @@ test_expect_success 'conflict at EOF without LF resolved by
>> --union' \
>>  test_expect_success 'conflict markers contain CRLF when core.eol=crlf' '
>>         test_must_fail git -c core.eol=crlf merge-file -p \
>>                 nolf-diff1.txt nolf-orig.txt nolf-diff2.txt >output.txt &&
>> -       test $(tr "\015" Q <output.txt | sed -n "/\.txtQ$/p" | wc -l) -eq 3
>> +       tr "\015" Q <output.txt | sed -n "/\.txtQ$/p" >out &&
>> +       cat >exp <<\EOF  &&
>> +<<<<<<< nolf-diff1.txtQ
>> +||||||| nolf-orig.txtQ
>> +>>>>>>> nolf-diff2.txtQ
>> +EOF
>> +        test_cmp exp out
>>  '
>>
> 
> This still doesn't test the '======= conflict marker', how about
> something like this (again not tested on Mac - is the re in the
> sed invocation OK on the Mac?):
sed is OK (The problem is the usage of "\r" inside sed:)

Linux:
printf "AA\r\n" | sed 's/\r$//' | od -c
0000000   A   A  \n

Mac OS:
printf "AA\r\n" | sed 's/\r$//' | od -c
0000000    A   A  \r  \n
0000004
> 
> diff --git a/t/t6023-merge-file.sh b/t/t6023-merge-file.sh
> index 245359a..0697b22 100755
> --- a/t/t6023-merge-file.sh
> +++ b/t/t6023-merge-file.sh
> @@ -350,7 +350,14 @@ test_expect_success 'conflict at EOF without LF resolved by --union' \
>  test_expect_success 'conflict markers contain CRLF when core.eol=crlf' '
>  	test_must_fail git -c core.eol=crlf merge-file -p \
>  		nolf-diff1.txt nolf-orig.txt nolf-diff2.txt >output.txt &&
> -	test $(sed -n "/\.txt\r$/p" output.txt | wc -l) = 3
> +	tr "\015" Q <output.txt | sed -n "/^[<=>|].*Q$/p" >out.txt &&
> +	cat >expect.txt <<-\EOF &&
> +	<<<<<<< nolf-diff1.txtQ
> +	||||||| nolf-orig.txtQ
> +	=======Q
> +	>>>>>>> nolf-diff2.txtQ
> +	EOF
> +	test_cmp expect.txt out.txt
>  '
>  
>  test_done
Your fix works under Mac OS.

Micro-nit: should the sed expression use -e (is that more Git style ?)
tr "\015" Q <output.txt | sed -n -e "/^[<=>|].*Q$/p" >out.txt &&
Micro.nit 2:
We can simplify and use grep instead:
tr "\015" Q <output.txt | grep "^[<=>|]" >out.txt &&

  reply	other threads:[~2016-01-01 22:24 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-01 15:36 t6023 broken under Mac OS Torsten Bögershausen
2016-01-01 17:14 ` Ramsay Jones
2016-01-01 17:49   ` Torsten Bögershausen
2016-01-01 21:14     ` Ramsay Jones
2016-01-01 22:23       ` Torsten Bögershausen [this message]
2016-01-02 19:35   ` Junio C Hamano
2016-01-02 20:06     ` Beat Bolli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5686FC72.8030008@web.de \
    --to=tboegi@web.de \
    --cc=dev+git@drbeat.li \
    --cc=git@vger.kernel.org \
    --cc=ramsay@ramsayjones.plus.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.