On Fri, Apr 08 2022, Christian Couder wrote:
> On Fri, Apr 8, 2022 at 6:10 AM <jurgen_gjoncari@xxxxxxxxxx> 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.
