Hi Junio, On Fri, 22 Jan 2016, Junio C Hamano wrote: > Johannes Schindelin <johannes.schindelin@xxxxxx> 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; -- 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