Re: [Bug] commit-tree shouldn't append an extra newline to commit messages

[Jeff King <peff@peff.net>]

On Fri, Sep 01, 2017 at 02:58:52PM -0400, Ross Kabus wrote:

> When doing git commit-tree to manually create a commit object, it can be seen
> that the resulting commit's message has an extra appended newline (\n) that
> was not present in the input for either argument -m or -F. This is both
> undesirable and inconsistent with the git commit porcelain command.

Hmm. As a plumbing command, I'd expect commit-tree to generally _not_
perform such niceties. And definitely it does not when taking the
message in via stdin. In Git's original design, commit object bodies do
not even have to be text, though certainly the porcelain tools all
assume they are.

But I am confused by your "inconsistent with git commit porcelain"
comment. The porcelain git-commit definitely _does_ add a newline if one
isn't present (and in fact runs the whole thing through git-stripspace
to clean up whitespace oddities).

So I don't think "inconsistent with git-commit" is a compelling
argument, unless I'm missing something.

I _could_ see an argument for "commit-tree as plumbing should always
treat the message verbatim". But since "-F" and "-m" have done the
newline-completion since their inception, I'm not sure it's a good idea
to change them now. The current behavior also makes some sense, as it's
consistent with the matching options in git-commit (again, as far as I
can see; if you have a counter-example it would be interesting to see).

-Peff