Re: [PATCH v3 3/3] Don't expand CRLFs when normalizing text during merge

From: Eyvind Bernhardsen <eyvind.bernhardsen@gmail.com>
Date: Jun 25, 2010, 07:58 UTC
Message-ID: <FB02F1B0-9FE7-4B7B-BA30-5A510F83BCE7@gmail.com>
In-Reply-To: <4C244278.10407@viscovery.net>

On 25. juni 2010, at 07.45, Johannes Sixt wrote:

Show 8 quoted lines

> Am 6/24/2010 22:44, schrieb Eyvind Bernhardsen:
>> There's no need to expand CRLFs when convert_to_working_tree() is called
>> to normalize text for a merge since the text will be converted back
>> immediately.  Improves performance of merges with conflicting line
>> endings when core.eol=crlf or core.autocrlf=true.
> 
> Pardon me, first you make a big deal about normalization for merges, only
> that you finally omit it? What am I missing?

Sorry, I didn't explain that very well.  I noticed that normalize_buffer() does more work when core.eol=crlf than it does when core.eol=lf: _to_working_tree() converts LF to CRLF, and then _to_git() reverses that conversion.  This patch makes normalization act the same way when core.eol=crlf as it does when core.eol=lf.

That implies a lack of symmetry in the way the crlf_to_git() and crlf_to_worktree() functions are called, but that asymmetry already exists when core.eol=lf since crlf_to_worktree() returns immediately when no output conversion is required.

I considered temporarily setting the "eol" and "auto_crlf" globals in normalize_buffer(), but messing with global variables felt wrong and this gives the same result (almost: it also disables conversion when a file has text=crlf, but that is a further optimization).

> BTW, most of the new functions you introduced violate the style: they
> should have the opening brace on the next line.

Ah, will fix.  Thanks.

-- 
Eyvind Bernhardsen