Hi Junio,
On Fri, 22 Jan 2016, Junio C Hamano wrote:
> Johannes Schindelin <johannes.schinde...@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;
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
