Re: [PATCH 2/2] merge-file: consider core.crlf when writing merge markers

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Jan 22, 2016, 18:47 UTC
Message-ID: <alpine.DEB.2.20.1601221937440.2964@virtualbox>
In-Reply-To: <xmqqmvrxv5tn.fsf@gitster.mtv.corp.google.com>

Hi Junio,

On Fri, 22 Jan 2016, Junio C Hamano wrote:

Show 15 quoted lines

> Johannes Schindelin <johannes.schindelin@gmx.de> writes:
> 
> > The original version of this patch also modified ll_merge(), but that
> > was incorrect: low-level merge operates on blobs, not on working
> > files.  Therefore, the data passed to the low-level merge, as well as
> > its result, is expected to have LF-only line endings.
> >
> > It is the duty of ll_merge()'s *caller* (in case of Git's `merge`
> > command, the merge_content() function) to convert the merge result
> > into the correct working file contents, and ll_merge() should not muck
> > with line endings at all.
> 
> Hmph, aren't there people who use CRLF throughout their set-up (that is,
> it is normal for both of their blobs and working tree files to use CRLF
> line endings)?  Or is such a setting illegal and unsupported?

Good point.

While I would love to simply not support such a case, it would be turning a blind eye to reality.

So I guess I need another patch like this (plus a test case):

-- snipsnap -- t a/ll-merge.c b/ll-merge.c index 0338630..4a565c8 100644

--- a/ll-merge.c
+++ b/ll-merge.c
@@ -111,6 +111,7 @@ static int ll_xdl_merge(const struct ll_merge_driver
*drv_unused,
 		xmp.style = git_xmerge_style;
 	if (marker_size > 0)
 		xmp.marker_size = marker_size;
+	xmp.crlf = eol_for_path(NULL, src1->ptr, src1->size) == EOL_CRLF;
 	xmp.ancestor = orig_name;
 	xmp.file1 = name1;
 	xmp.file2 = name2;