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

From: Jeff King <peff@peff.net>
Date: Sep 2, 2017, 08:33 UTC
Message-ID: <20170902083319.lcugfpkkk5lahieb@sigill.intra.peff.net>
In-Reply-To: <CAEVs+za9do_wXC12SSRznF9v9oGw3_Grq2EFDVf8nH1CRgM-Qw@mail.gmail.com>

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