Re: Bug-ish: CRLF endings and conflict markers

From: Andy Parkins <andyparkins@gmail.com>
Date: Jan 11, 2007, 11:36 UTC
Message-ID: <200701111136.23864.andyparkins@gmail.com>
In-Reply-To: <Pine.LNX.4.63.0701111043440.22628@wbgn013.biozentrum.uni-wuerzburg.de>

On Thursday 2007 January 11 09:46, Johannes Schindelin wrote:

Show 5 quoted lines

> > The best solution is probably to use the line ending of the conflicted
> > lines.
>
> Question is: how to find out. Especially if your file already has mixed
> line endings...

That's why I said use the line endings of the conflicted lines. Even if the file is mixed, at least lines added are the same as the ones near them. Let's say for example a conflict like this:

<<<< Whole file has DOS endings^M ==== The whole file has DOS endings^M

>>>>

As both of the conflicted parts end in CRLF, the conflict markers would default to having CRLF. This would cope with mixed-ending files as well, as the ending is always determined locally.

If we were being really clever, we could make each marker use the ending of the line following it; making it impossible to accuse git of doing anything worse than already existed.

> No. It would be in xdiff/xmerge.c:{139,147,160}. But I think that xdiff

Thanks; I see why I couldn't find it: it's generated as a loop "marker_size" long, rather than the literal that is in rerere. I've had a quick glance at xdl_fill_merge_buffer() and can see it's not an easy thing to do (at least for me). Maybe if it itches me a bit more I'll put some effort into my scratching :-)

> really is LF-only throughout, so you'd have to do much more work anyway.

That doesn't seem to be a problem. git is performing very nicely on the CR-LF file I'm tracking. As I mentioned, it's treating the CR as just another character on the line - perfect: merges, diffs, diffstats all work just fine.

Andy

-- 
Dr Andy Parkins, M Eng (hons), MIEE
andyparkins@gmail.com