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 -- 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