Re: [PATCH] Add testcase for merging in a CRLF repo, showing that conflict file is in LF only

[Johannes Sixt <j.sixt@viscovery.net>]

Marius Storm-Olsen schrieb:
> Johannes Sixt said the following on 09.06.2008 15:37:
>> Marius Storm-Olsen schrieb:
>>> An LF only conflict file results in the resolved file being in LF,
>>> the commit is in LF and a warning saying that LF will be replaced
>>> by CRLF, and the working dir ends up with a mix of CRLF and LF files.
>>
>> After reading these 3 lines I've no idea what you are talking about. Can
>> you translate this to English, please? ;-)
> 
> Certainly :-)
> It means that if you work on a repo with core.autocrlf == true, you'd
> expect every text file to have CRLF EOLs. However, if you by some
> operation, get a conflict, then the conflicted file has LF EOLs.
> Now, of course you'd go about resolving the files conflict, and then
> 'git add <file>'. When you do that, you'll get the warning saying that
> LF will be replaced by CRLF. Then you commit. The end result is that you
> have a workingdir with a mix of LF and CRLF files, which after some more
> operations may trigger a "whole file changed" diff, due to the
> workingdir file now having LF EOLs.

Aha! Care to write it this way in the commit message in the next round? ;)

>>>  Sorry, no patch to actually *fix* the problem.
>>
>> Then you should use test_expect_failure instead of test_expect_success.
>> And maybe also mention it in the commit message.
> 
> Well, the test case is written in a way that it *should* pass (iow, it
> _expects_ a success), but it currently doesn't. So, the goal is that
> someone, who is more intimate with the code, can just run the testcase
> until it passes (fixing in between each run, of course ;-)

test_expect_failure has changed its meaning. It's now used to say precisly
what you describe here.

It means: "We should expect this command sequence to complete
successfully, but we know that there is a bug in a git command, and hence
we must expect failure until it is fixed."

Such a test is marked as "still broken", and the test run is not
interrupted. If the bug is fixed, the test is marked as "FIXED" until the
'test_expect_failure' is turned into 'test_expect_success'.

>>> +test_expect_success 'Check that conflict file is CRLF' '
>>> +    git reset --hard a &&
>>> +    ! git merge side &&
>>
>>     test_must_fail git merge side &&
> 
> Ah, I checked a few other testcases, where I saw the ! construct. I
> don't mind changing it, if it's important. Does it add 'feature' to the
> testcase by using test_must_fail, instead of '!' ?

'! git cmd' says that any unusual exit is ok, even a segfault and
incorrect usage. 'test_must_fail git cmd' says that only deliberate error
exits are ok.

-- Hannes