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.
