On Thursday 2007 January 11 09:46, Johannes Schindelin wrote:
> > 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@xxxxxxxxx
-
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