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

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Mon, Apr 5, 2010 at 05:51, Jeff King <peff@peff.net> wrote:
> So yes, it sucks that his importer does not support empty comments, and
> that the OP had to hack around it. But it already doesn't support many
> things (like commits with a large number of files, and from what I can
> see, files with spaces will break his `find` invocation). The right
> answer is for him to move to fast-import, which will be way faster, more
> robust, and is actually a supported plumbing interface.

Thanks for looking at the importer, that'll be very useful when fixing
it. But FWIW that `find` invocation isn't a bug. Perl doesn't have a "
" input field separator so "my @files = `find . -type f`" does the
right thing, unlike in the shell.

> I don't think it's worth adding new features to support a scripting
> interface that we are trying to discourage. And I haven't seen another
> argument in favor of empty commits besides importing.  Are people
> really wanting to make empty commit messages while using git itself?

I'm sorry that I brought snerp-vortex into this at all. It wasn't the
main motivation behind this patch, just the straw that broke the
camel's back.

I've run into this limitation a lot when playing with and learning
Git. Sometimes I'm e.g. making small throwaway repositories in /tmp
using the porcelain for  experimentation. Those have seen a lot of
"blah!" commit messages immediately following "Git exited abnormally
with code 1".

Miles Bader said it better than I could. Tools should provide sane
defaults and discourage bad practices, but they shouldn't *enforce*
good practices. That'll inevitably burn people whose use for the tools
isn't what you expect.

Even if they Git maintainers don't like this people *do* write
automated scripts and wrappers around Git using the porcelain, simply
because that's what they're used to. Learning to use and switching to
something like git-fast-import(1) or git-commit-tree(1) is too big of
a hurdle for small throwaway scripts that take ~1m to write and aren't
big dedicated importers like snerp-vortex.

There's probably a lot of code out there doing `git commit -m"Yet
another revision"' from some cron job. I sprinkled a lot of such
meaningless messages about when I switched from Subversion (which
supports empty commits in the porcelain) for these automated jobs to
Git.

Of course Junio may disagree (and that's fine!), how much you babysit
your users is ultimately a design decision up to the maintainer. I
just find this inconsistent with the rest of the porcelain which
usually gives me plenty of ammo to blow both my legs of (and the
planet they were standing on) if I so choose :)