Hi Junio, On Fri, 22 Jan 2016, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > > >> > 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; > > What I do not understand is that you already had xmp.crlf even the > log message claimed that the caller is supposed to feed LF blobs and > the ll_merge() shouldn't have to worry about this. Well, I just heeded your point about blobs not necessarily having LF-only end-of-lines ;-) In any case, the upcoming iteration works quite a bit differently, and I want to add, robustly. Ciao, Dscho -- 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