Re: Make commit messages optional

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

On Mon, Apr 11 2022, tytso wrote:

> On Mon, Apr 11, 2022 at 12:19:51PM +0200, Ævar Arnfjörð Bjarmason wrote:
>> > and the main argument *against* is "for most
>> > people (non-advanced users), what you do initially is what you end up
>> > pushing, or at least trying to push, and fixing things later is *hard*
>> > - it requires a much deeper understanding of git than most people
>> > otherwise necessarily need to develop".
>> 
>> 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.
>
> So possible options we could consider:
>
> 1) Do nothing.  If users want to override the current behavior they
> can just put in their .git/config or ~/.gitconfig file:
>
> [alias]
>    commit = commit --allow-empty-message

You cannot use aliases to override built-in commands, so this won't
work.

> 2) Add some kind of explicit git-config option which could then be
> added to their .git/config or ~/.gitconfig:
>
> [commit]
>    allow-empty-description = true
>
> 3) Change the default, so that --allow-empty-message is always
> implied, and hope that novices can figure out git rebase -i without
> shooting themselves in the foot.
>
> 4) Enforce git push doesn't push commits with empty commits,
> implemented on the client side.  This could be implemented via a
> pre-push hook script.
>
> 5)  Enforce git push doesn't push commits with empty commits,
> implemented on the server side.This could be implemented via a
> pre-receive hook script.
>
> I will note that only options 2 and 3 require source code changes to
> git.  The rest can effectively be done via config file changes; for
> the hook files, we could provide example scripts to make it easier for
> people to choose that particular option.
>
> And of these options, only one option, #3, requires imposing someone's
> preference (which does appear to be in the minority) on everyone
> else.

We could add configuration or whatever, but the topic of this thread is
whether we should change the *default*. I think it's better to stick to
that.