Re: [PATCH] mergetool: respect autocrlf by using checkout-index

From: Charles Bailey <charles@hashpling.org>
Date: Jan 26, 2009, 16:31 UTC
Message-ID: <20090126163114.GD32604@hashpling.org>
In-Reply-To: <83skn6doxm.fsf@kalahari.s2.org>

On Mon, Jan 26, 2009 at 06:15:01PM +0200, Hannu Koivisto wrote:

Show 19 quoted lines

>
> Now that I tried the patch, I observed that while the stage2 and
> stage3 temporary files have CRLF line endings, the merge result
> buffer/file has LF line endings.  I'm again using Cygwin git,
> mergetool -t emerge and native Windows Emacs.  So when I quit the
> mergetool, I get
> 
> ...
> Hit return to start merge resolution tool (emerge):
> warning: LF will be replaced by CRLF in kala.txt
> warning: LF will be replaced by CRLF in kala.txt
> 
> and indeed hexdump proves that the file in my worktree now has LF
> line endings even though it had CRLF line endings before invoking
> mergetool.
> 
> I wonder why I didn't notice this the first time.  I can certainly
> reproduce it now without Charles' patch as well so I suppose this
> is a separate issue and the patch does what it is supposed to do.

mergetool doesn't touch the destination file, it just asks the merge tool to overwrite it.

I suspect that the LF endings in the file is due to the fact that in builtin-merge-file.c, the file is opened (fopen) in binary mode ("wb"), but xdl_merge terminates all lines with a raw '\n'.

The obvious fix would be to change fopen in builtin-file-merge.c to use "w" instead, but this doesn't work in a number of scenarios. In particular, it is wrong for repositories on windows with core.autocrlf set to false, and would not fix non-windows repositories with core.autocrlf set to true.

Currently, I've no idea as to what the solution should be.

-- 
Charles Bailey
http://ccgi.hashpling.plus.com/blog/