Re: [PATCH] Add option to git-commit to allow empty log messages

In retrospect I probably should have sent a [PATCH RFC], this is
obviously somewhat of a delicate subject.

On Sun, Apr 4, 2010 at 21:21, Shawn Pearce [off-list ref] wrote:

Isn't this exactly why git-commit-tree exists?  I don't really see a reason
to support scripting the porcelain git commit.

It's not so much about supporting scripting as exporting the
capabilities of the porcelain to the frontend utilities without
artificial limitations.

On Sun, Apr 4, 2010 at 22:43, David Aguilar [off-list ref] wrote:

On Sun, Apr 04, 2010 at 02:49:16PM +0000, Ævar Arnfjörð Bjarmason wrote:

quoted

Change git-commit(1) to accept a --allow-empty-message option
analogous to the existing --allow-empty option which allows empty
trees. This is mainly for compatability with foreign SCM systems.

Is there any reason why the git commit-tree plumbing didn't
suffice?

I encountered this limitation most recently while using hacking
snerp-vortex which uses git-commit(1) directly. While it should
ideally use git-commit-tree(1) or git-fast-import(1) it was easier at
the time to do:

    message ||= "Git made me";

I thought it was silly that I had to either do that to fix an
otherwise working piece of software or rewrite how it does commits,
hence the patch.

It's hard enough to get co-workers to write good commit
messages.  I wouldn't want to encourage them to skip writing
them altogether (by the existence of this feature).

I'm a big fan of good commit messages, that's another reason why I
think this feature is a good idea.

I've read too many commit messages from people who're obviously
determined not to write any, but are being forced to do so by their
tools. Favorites include "more updates", "some changes", "..." (the
list goes on). I'd rather get nothing at all from those people than
more meaningless drivel. It would increase the signal-to-noise ratio
of git-log(1) output.