On Mon, Jan 26, 2009 at 06:15:01PM +0200, Hannu Koivisto wrote:
>
> 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/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
