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@xxxxxxxxxxx> 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@xxxxxxxxx> wrote:
> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html