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

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Apr 5, 2010, 12:50 UTC
Message-ID: <o2h51dd1af81004050550v9427b9flfb13a9e1ad4056a@mail.gmail.com>
In-Reply-To: <20100405055139.GA28730@coredump.intra.peff.net>

On Mon, Apr 5, 2010 at 05:51, Jeff King <peff@peff.net> wrote:

Show 6 quoted lines

> 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 :)