At the risk of bikeshedding. The case in favor of not allowing empty commit messages by default is that most of the time, empty commit messages are useless. I've written my fair share of poor commit messages (-,..., wip, foo). Sometimes I've fixed that retroactively, sometimes not. The advantage I see with empty commit messages is that it's more ubiquitous to "write something better" or "whatever". The downside is I can't git log --grep '^$' to find them. On Fri, Apr 8, 2022 at 7:47 PM Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> wrote: > > I think one of the best things about git's design is how in most other > areas we've really leaned into that design ethos. I.e. you can commit > whatever train-of-thought garbage you want, but we make it really easy > to interactively rebase all of that before pushing (or "finalizing") it. True. But this is power-user territory. AFAIK, very few users rebase -i and very few tools support interactive rebasing. Those that do probably have no problem aliasing git commit to adapt to that workflow on their own, without different defaults. > E.g. I wouldn't mind if we made pushes start failing (probably guarded > by appropriate isatty() checks) if the user was pushing content without > commit messages, unless some option were overridden, or we could start > sternly warning about that. Ditto for merging a branch into another one > (especially if we can see it's the default branch). I could see this being a potentially nice option but also pretty much .git/hooks/pre-push.sample but with rev-list --grep '^$' (which doesn't appear to work) > 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 agree in spirit, but also feel obliged to point out the immutability of commit messages in most user workflows. In such workflows, the propagation in a sense becomes the point of commiting. My experience is that in most typical GUI workflows, the writing of a commit message is not a very high point of friction. These environments typically instead favor larger commits due to friction of staging/unstaging. In such situations, it's more important to write a commit message that at least says *something*.
