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

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi Junio,

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

> Johannes Schindelin <Johannes.Schindelin@gmx.de> 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