Re: [PATCH 0/2] Reinstate the helpful message when `git pull --rebase` fails

[Johannes Schindelin <johannes.schindelin@gmx.de>]

Hi Torsten,

On 2015-10-10 18:05, Torsten Bögershausen wrote:
> On 09.10.15 12:11, Johannes Schindelin wrote:
>> Me again,
>>
>> On 2015-10-09 11:50, Johannes Schindelin wrote:
>>>
>>> On 2015-10-09 03:40, Paul Tan wrote:
>>>> On Fri, Oct 9, 2015 at 8:52 AM, Junio C Hamano <gitster@pobox.com> wrote:
>>>>> Johannes Schindelin <johannes.schindelin@gmx.de> writes:
>>>>>
>>>>>> Brendan Forster noticed that we no longer see the helpful message after
>>>>>> a failed `git pull --rebase`. It turns out that the builtin `am` calls
>>>>>> the recursive merge function directly, not via a separate process.
>>
>> [... cut lots of unnecessary text ...]
>>
>> +test_expect_success 'failed --rebase shows advice' '
>> +	git checkout -b diverging &&
>> +	test_commit attributes .gitattributes "* text=auto" attrs &&
>> +	sha1="$(printf "1\\r\\n" | git hash-object -w --stdin)" &&
>> +	git update-index --cacheinfo 0644 $sha1 file &&
>> +	git commit -m v1-with-cr &&
>> +	git checkout -f -b fails-to-rebase HEAD^ &&
>> +	test_commit v2-without-cr file "2" file2-lf &&
>> +	test_must_fail git pull --rebase . diverging 2>err >out &&
>> +	grep "When you have resolved this problem" out
>> +'
>> +
> 
> One other question:
> Is it good to mix 2 different things in one test case ?
> "shows the helpful advice when failing" is one thing,
> and the problematic CRLF handling another.

I do not necessarily test things that work, and have been working for a long time, so no, I do not want to split that into two.

I could trigger the regression only via CR/LF, that is the only reason why CR/LF are used here. I do *not* want to test for anything CR/LF specific.

Ciao,
Dscho