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

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Apr 4, 2010, 23:53 UTC
Message-ID: <y2j51dd1af81004041653g9a09915el60104c575dcf6481@mail.gmail.com>
In-Reply-To: <20100404224324.GB12655@gmail.com>

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 <spearce@spearce.org> 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 <davvid@gmail.com> wrote:

Show 7 quoted lines

> On Sun, Apr 04, 2010 at 02:49:16PM +0000, Ævar Arnfjörð Bjarmason wrote:
>> 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.