Hi Eli, Thank you for the suggestion.
> no similar explanation is provided for the output. The explanation is the general "Newline Guidelines" from unicode.org: <http://www.unicode.org/versions/Unicode6.2.0/ch05.pdf#G10213> p. 156 rule R3a: "If the intended target is unknown, map to the platform newline convention." And rule R4a as well. > The result is that, when the program runs on MS-Windows, the merged > ChangeLog file is always output with the DOS-style CR-LF EOLs. This > gets in the way when git's core.autocrlf config option is set to > false, because almost all projects have ChangeLog files in Unix > LF-only EOL format, and the merged file will have all of its lines > modified. Oops! According to the git documentation <http://git-scm.com/book/ch7-1.html>, section "core.autocrlf", the setting git config --global core.autocrlf input should be perfect for Windows users. I can understand why you don't want git config --global core.autocrlf true (namely if you work a lot with Cygwin / Unix tools). Given the above general rule, I believe that git-merge-changelog is not the only program that outputs CR-LFs on Windows, for input that had only LF as line terminator. Therefore setting core.autolf to 'true' should be the better solution, compared to modifying git-merge-changelog. > + p = strchr (buf, '\n'); > + > + if (p > buf) > + { > + if (p[-1] == '\r') > + result = true; > + } > + } If, despite your expectations, the first line is longer than 255 bytes, p will be NULL, and with a high probability on Linux/x86 (buf being stack-allocated, it is at an address between 0x80000000 and 0xC0000000), p > buf will evaluate to true, and the next statement will crash. Bruno
