Re: Make commit messages optional

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Apr 8, 2022, 11:26 UTC
Message-ID: <220408.86r167bxra.gmgdl@evledraar.gmail.com>
In-Reply-To: <CAP8UFD2Tk-FuGcFN0DEKK6g3O8G=SGuU99FPRRqPM_-39i9t0A@mail.gmail.com>

On Fri, Apr 08 2022, Christian Couder wrote:

Show 22 quoted lines

> On Fri, Apr 8, 2022 at 6:10 AM <jurgen_gjoncari@icloud.com> wrote:
>>
>> I think that often commit messages are unnecessary. I propose that by default a user should be able to commit without a message.
>
> We prefer to encourage users to do the right thing by default and
> provide a commit message. We think that good software development
> practices should be encouraged and that providing a good commit
> message is good software development practice.
>
>> I don't think this would be a problem from the UX point of view,
>> because a user could get a lot of information about a change, from
>> the history of the GitHub repository, such as from the time of
>> change, and seeing the diff.
>
> What about `git log --oneline`?
>
>> I think that making commit messages options wouldn't even be a problem for retro compatibility because the feature would remain still functional for those who would want to use it.
>
> Yeah, there is no compatibility issue because `git commit` already has
> an `--allow-empty-message` option, so empty commit messages are
> already supported. That's not a good reason to make it the default
> though.

I agree that we should do away with the check for the empty commit message.

I also added --allow-empty-message in the first place, so I'm a bit biased.

Now, anyone who's seen pretty much any of my commits knows I don't have much of an issue with writing commit messages when it matters.

But to get around this requirement of git I've got a local alias that basically does:

    git commit -m"$(line from http://whatthecommit.com/)"

I could use --allow-empty-message, but I think at some point we still had tooling (git am?) that was annoying to use with it, so I settled on that "solution", and muscle memory dies hard (I've got a short alias for this thing)>

In general I wish git were more helpful and less opinionated. It's fine to have sane defaults, or to help users, but e.g. this case I think was always better handled with an advise() or something.

Git is also used in a lot of contexts that aren't "normal" software development, e.g. the "gist" feature on GitHub creates commits without commit messages.

Now, of course they know about --allow-empty-message, and users *can* find it too. But UX friction is like taxation, you add friction where you want to discourage things, and sometimes users are discouraged entirely because you've added that cost. After all you probably know better, maybe they shouldn't be doing that with the tool. Or they never check that it *can* be done, and just stop because it's erroring by default.

But even if git were only used for software development I think adding this friction *there* is entirely misguided.

It's perpetuating the notion that there shouldn't be a disconnect between "what you commit" and "what you push".

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.

Which, as an aside is a notable difference to the fossil SCM system, which heavily leans into the exact opposite notion. I.e. that thou shalt not alter work already committed (even if not "pushed").

So I'd really like to see (from someone who's got more interest & time to work on this) some change to this default limitation that steered users more towards use cases we actually care about.

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

All of those things would actually have some hope of aligning with what we're *actually* trying to encourage.

But doing this at the point of commits? I think it just amounts to some misguided rear-guard action, and it's actually doing more harm than good.

We're encouraging users to think that there's a 1=1 mapping between commit message and time of commit/snapshot. If I had to pick one thing that's the difference between a beginner novice git user and someone who's an intermediate/advanced it's knowing that there's a disconnect between the two, and using it to one's advantage (i.e. rebase -i before pushing)>

All that being said I think a perfectly good incremental step would be to make --allow-empty-message the default, and just replace it with some advise() instead.

We could even emit such advise() e.g. if we see the message is shorter than some length, or if there's a big delta between commit message length & diff length. Both of those things would be a lot easier than the suggested "error on push" above, and wouldn't require revision walking, just a small change or check in builtin/commit.c.

But of course any such changes would need to get through list review, and I know there's a lot of people who feel quite strongly about this in the opposite direction.

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.