Bug-ish: CRLF endings and conflict markers

Hello,

I am sure the response to this will be "tough", however I'll mention it anyway. It wasn't a problem for me, as I know git is LF endings only, but others might be a bit confused.

 * Track a file that has CR-LF endings.  Not a problem, git works fine with 
   these and treats the CR as an extra character at the end of the line.
 * Have two branches make conflicting changes to that file
 * Merge, conflict
 * Open the file
 * Find that (almost) every line now displays with a "^M" at the end.  vim has
   found some lines that don't have CR-LF ends so dropped back to UNIX mode.
 * Be careful that your conflict resolution doesn't introduce any new lines as 
   they will not have CR-LF endings.

The "(almost)" above refers of course to the conflict markers. These have LF endings only so force the editor into UNIX mode. Assuming a binary safe editor, things will be fine if the conflict resolution is simply to remove the markers, and edit the existing lines. However, if the user adds any lines during conflict resolution, those new lines will only have LF ends.

This is a problem for compilers that are expecting CR-LF input.

Note: this is not on Windows (spit), this is simply editing a CR-LF file on 
UNIX.

The best solution is probably to use the line ending of the conflicted lines. I've had a look, but I can only fine builtin-rerere.c that generates the markers - would that be the place to make this change?

Andy