Re: Make commit messages optional

On Sun, Apr 10 2022, Tao Klerks wrote:

Or don't fix it later, e.g. in the gist case mentioned in [1]. As shown in [2] forcing the user to provide a message can serve to increase the noise to signal ratio, in making it harder to distinguish those commits where the author had nothing to say.

I have numerous local repos where I'd benefit from --allow-empty-message by default (of course I can customize it, but habits etc). Now through some combination of scripting and habits I've ended up with e.g.:

    git commit -mbump

These are things like my local (private) notes file, a repo that keeps snapshots of E-Mails I send to the Git ML etc. Those things are newer going to have meaningful commit messages.

Yes, maybe it won't be viable to go in that direction, but re this in my
[1]:
	
	But I'm also pretty sure that those people are engaged in a proxy war,
	and we should just attack the "problem" directly instead. I.e. it's not
	a problem that some commit somewhere has an empty message, rather it's
	that such a commit gets "propagated". A better place to check for it is
	then at the point of point of propagation.

I think it would be useful if those advocating for this behavior would indicate whether or not some working solution of doing it in a different place would address their concerns, whether or not we have patches ready for that.

E.g. something that (if you have empty commit messages) would prompt you to interactively rebase the to-be-pushed history or whatever.

Another thing that occurred to me after sending [1] was that perhaps "repo size" would be good heuristic, we already have a fast estimation of that for showing abbreviated commit OIDs.

That wouldn't do the right thing on e.g. large private git-annex repos,
but would serve to distinguish a "real, mid-size or large repo" like
git.git, redis.git, linux.git etc. from dotfiles, gists etc.
	

I agree with that if you s/allowing people to create empty/force people to create non-empty/ :)

I think all the arguments in this thread (including mine) are ultimately built on anecdotes, and I don't think that we can hope to get out of that rut.

E.g. I've helped a lot of novice people with git (being the go-to "git guy" at a past job), and one of *the most common* things I encountered was users with some absolute mess of a working tree with large outstanding changes, which ultimately came down to them being afraid to commit it as it "wasn't ready".

So I really think anything we can do to break that particular pattern is more helpful than not.

But am I absolutely confident that I'm right, and that these concerns will outweigh other anecdotes brought up in this thread? No.

But what I am confident in saying is that tweaking the UX in this area will have cost/benefits whatever you do, and I think that whatever "side" one picks here the interesting arguments to be had is trying to discuss and mitigate those costs.

Note that that's a pretty narrow reading of [1]. The main thrust of my point was that we should consider moving this to "push" or "merge" time.

I think that's a lot worse than the status quo, at least now our
behavior just seems like a very basic safeguard, e.g.:
	
	$ git commit -a
	hint: Waiting for your editor to close the file... Waiting for Emacs...
	Aborting commit due to empty commit message.

There I opened my editor, saved the empty file that came up ("empty" when adjusted for comments), and "git commit" aborted.

Even if I think we should make some version of "allow empty" the default I think *that* particular thing should stay.

I.e. that's really helping a user to mitigate a genuine mistake, particularly if something goes wrong with the external editor. I.e. I think something like this would be sufficient (as in, it should succeed):

    $ git commit -a --no-edit
    Aborting commit due to empty commit message.

All of those would be good cases to get feedback on, i.e. let's leave aside the question of whether the UX should "encourage" and whether --allow-empty-message should be the default, do the proponents of the status quo think all of these are sensible:

    git commit -a # launches editor
    git commit -a -m"" # empty message
    git commit -a --no-edit # no editor

Aside from anything else I think --allow-empty-message for that last one is rather silly, it's basically making the user say --yes-i-know-the-default-messages-is-the-empty-message. Maybe it's arguably in the case of a pre-commit hook & without --no-verify?

Anyway, that was a bit of a digression, sorry.

The reason I think it's "worse than the status quo" is that it takes us from something that seems to be an overzelous CLI option check gone wrong to actively recommending a "novice forever" UX pattern. I.e. the "reduce the understandability of the commit history" etc. assumes or implies that we won't have a "git rebase -i" before pushing.

1. https://lore.kernel.org/git/220408.86r167bxra.gmgdl@evledraar.gmail.com/
2. https://lore.kernel.org/git/220411.865ynfkj7r.gmgdl@evledraar.gmail.com/