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 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. - Ted
