Re: git-merge-changelog and EOL format on Windows

[Bruno Haible]

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