Make commit messages optional

Make commit messages optional

[jurgen_gjoncari]

I think that often commit messages are unnecessary. I propose that by default a user should be able to commit without a message. 

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. 

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. 

Re: Make commit messages optional

[Christian Couder]

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.

Re: Make commit messages optional

[Ævar Arnfjörð Bjarmason]

On Fri, Apr 08 2022, Christian Couder wrote:

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

Re: Make commit messages optional

[Erik Cervin Edin]

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@gmail.com> 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*.

Re: Make commit messages optional

[Ævar Arnfjörð Bjarmason]

On Fri, Apr 08 2022, Erik Cervin Edin wrote:

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

You can:

    git log --invert-grep --grep '.'

> On Fri, Apr 8, 2022 at 7:47 PM Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:
>> 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)

The reason it doesn't work is that our --grep doesn't allow for matching
across the whole message, we should fix that, it would be useful in
other contexts.

But for this the --invert-grep above will do what you want. I.e. if our
--grep matches any one character and we discard any that matched with
--invert-grep we're left with empty commit messages.

Re: Make commit messages optional

[Junio C Hamano]

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

> On Fri, Apr 08 2022, Erik Cervin Edin wrote:
>
>> 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.
>
> You can:
>
>     git log --invert-grep --grep '.'

Wow, that's nasty.

In any case, "--allow-empty-messages" exists, and that is where we
draw the line.  We will not bend over backwards beyond it.

Thanks.

Re: Make commit messages optional

[Michal Suchánek]

On Mon, Apr 11, 2022 at 10:59:47AM -0700, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> 
> > On Fri, Apr 08 2022, Erik Cervin Edin wrote:
> >
> >> 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.
> >
> > You can:
> >
> >     git log --invert-grep --grep '.'
> 
> Wow, that's nasty.
> 
> In any case, "--allow-empty-messages" exists, and that is where we
> draw the line.  We will not bend over backwards beyond it.

Isn't special-casing the empty message bending over backwards to some
other influence instead?

Thanks

Michal

Re: Make commit messages optional

[Junio C Hamano]

Michal Suchánek <msuchanek@suse.de> writes:

>> In any case, "--allow-empty-messages" exists, and that is where we
>> draw the line.  We will not bend over backwards beyond it.
>
> Isn't special-casing the empty message bending over backwards to some
> other influence instead?

Not at all.

Even though the low level plumbing commands try to be accomodating
to people with different tastes, the Porcelain layer is opinionated
itself, and tries to give defaults that encourage good development
practice to interactive users.  There is no need for some other
influence---we chose to reject creating commits with empty messages
to prevent mistakes that novices may find hard to recover from,
and that's final.

Re: Make commit messages optional

[Philip Oakley]

Hi Jurgen

On 08/04/2022 04:35, 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. 
>
> 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. 
>
> 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. 

Isn't this an ideal candidate for an alias that simply passes in the
empty message?

However, it's worth reviewing and doing a retrospective about commit
messages and who they are there to inform.

They (these supposedly informative messages) used to frustrate me many
years ago. I already _knew_ what I was doing, and it was 'obvious', what
even needed saying (so say nothing).

The Git project's style has been informative in showing how to provide a
well focussed concise message that should be understandable to others,
to your future self, and help clarify one's current understanding of the
problem at hand. Often the last point will mean one upgrades the code to
meet the real need.

--
Philip

Re: Make commit messages optional

[Phillip Susi]

jurgen_gjoncari@icloud.com writes:

> I think that often commit messages are unnecessary. I propose that by

You would be wrong :)

Re: Make commit messages optional

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 2727 bytes --]

On 2022-04-08 at 03:35:04, 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. 

This topic comes up from time to time and you can see the previous
discussion in the archives.  The reasons we haven't done this are
roughly as follows.

First, writing commit messages is a way of communicating to others about
your changes, as well as to future you.  In my experience, it is
substantially more important in software engineering to communicate
clearly and effectively than it is to write code.  The computer will
accept anything that runs, but when you write code others must read it
and change it, and they must have the appropriate context behind those
changes to evaluate your changes and to make their own in the future.
We want to encourage good software engineering practices.

Tools like git log use the commit message, and empty commit messages
mean that viewing the list of commits is completely useless without
viewing a diff.  This means that functionality such as `git log --graph`
is just completely broken.  Writing even one line in the commit summary
makes a massive difference in the usability of these tools.

Users who want this behaviour can use --allow-empty-message or create an
alias with that option.  The functionality already exists.  I use
aliases extensively in my development and I know others do as well, so
this shouldn't be an impediment if you're working on projects where this
is acceptable.

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

I certainly hope when you are writing code that you explain your changes
somewhere.  I know some people who use pull requests prefer to do so in
the pull request rather than the commit message, but I for one would
never accept a change that doesn't contain some sort of explanation
about why it's valuable or relevant somewhere.  I am, unfortunately, not
omniscient, so I need people to communicate their intentions and
decisions to me, and the best way to do that is with words.

I should also point out that the GitHub UI is specifically designed to
show the commit summary in the history view, so GitHub intends for you
to write at least one line of helpful text (the summary) in this
context.

Overall, I don't believe your proposal is likely to gain traction here
for the reasons I mentioned above, and I personally don't support it.
-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

RE: Make commit messages optional

[rsbecker]

On April 8, 2022 6:30 PM, brian m. carlson wrote:
>On 2022-04-08 at 03:35:04, 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.
>
>This topic comes up from time to time and you can see the previous discussion in
>the archives.  The reasons we haven't done this are roughly as follows.
>
>First, writing commit messages is a way of communicating to others about your
>changes, as well as to future you.  In my experience, it is substantially more
>important in software engineering to communicate clearly and effectively than it is
>to write code.  The computer will accept anything that runs, but when you write
>code others must read it and change it, and they must have the appropriate
>context behind those changes to evaluate your changes and to make their own in
>the future.
>We want to encourage good software engineering practices.
>
>Tools like git log use the commit message, and empty commit messages mean that
>viewing the list of commits is completely useless without viewing a diff.  This
>means that functionality such as `git log --graph` is just completely broken.  Writing
>even one line in the commit summary makes a massive difference in the usability
>of these tools.
>
>Users who want this behaviour can use --allow-empty-message or create an alias
>with that option.  The functionality already exists.  I use aliases extensively in my
>development and I know others do as well, so this shouldn't be an impediment if
>you're working on projects where this is acceptable.
>
>> 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.
>
>I certainly hope when you are writing code that you explain your changes
>somewhere.  I know some people who use pull requests prefer to do so in the pull
>request rather than the commit message, but I for one would never accept a
>change that doesn't contain some sort of explanation about why it's valuable or
>relevant somewhere.  I am, unfortunately, not omniscient, so I need people to
>communicate their intentions and decisions to me, and the best way to do that is
>with words.
>
>I should also point out that the GitHub UI is specifically designed to show the
>commit summary in the history view, so GitHub intends for you to write at least
>one line of helpful text (the summary) in this context.
>
>Overall, I don't believe your proposal is likely to gain traction here for the reasons I
>mentioned above, and I personally don't support it.

The commit message is an essential part of why a change was made, in particular for forensics when something goes wrong, or when you are trying to figure out why you did something. Without a commit message, you are saying, "yeah, ok, something happened." It's up there with reporting a bug saying, "It doesn't work", with no additional details - I have customers who do that, and it is not helpful. To be harsh about it, if someone commits something with no or a useless message, I will reject the change with impunity. Not explaining yourself is not helpful to those who come after. It's up there with "Why did you not document your code, when you used single letter variables and strung the whole program on one line because C (or APL) allows it," with an answer along the lines of "Any decent developer should be able to figure out the code." Sorry, but I feel very strongly on the subject that this is not a good idea. If you want to put junk in your commit, that is your business, but expect a significant segment of the population looking at your repo on GitHub to judge harshly. This sounds more like "I don't want to use a version control system, but I have to for some reason, like HR metrics." I know I am being harsh on this, and I apologize in advance for it if I offended anyone, but I would want a way to disable (potentially at build time) this if it ever went forward.

My $0.04
--Randall

Re: Make commit messages optional

[Michal Suchánek]

On Fri, Apr 08, 2022 at 07:32:03PM -0400, rsbecker@nexbridge.com wrote:
> On April 8, 2022 6:30 PM, brian m. carlson wrote:
> >On 2022-04-08 at 03:35:04, 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.
> >
> >This topic comes up from time to time and you can see the previous discussion in
> >the archives.  The reasons we haven't done this are roughly as follows.
> >
> >First, writing commit messages is a way of communicating to others about your
> >changes, as well as to future you.  In my experience, it is substantially more
> >important in software engineering to communicate clearly and effectively than it is
> >to write code.  The computer will accept anything that runs, but when you write
> >code others must read it and change it, and they must have the appropriate
> >context behind those changes to evaluate your changes and to make their own in
> >the future.
> >We want to encourage good software engineering practices.
> >
> >Tools like git log use the commit message, and empty commit messages mean that
> >viewing the list of commits is completely useless without viewing a diff.  This
> >means that functionality such as `git log --graph` is just completely broken.  Writing
> >even one line in the commit summary makes a massive difference in the usability
> >of these tools.
> >
> >Users who want this behaviour can use --allow-empty-message or create an alias
> >with that option.  The functionality already exists.  I use aliases extensively in my
> >development and I know others do as well, so this shouldn't be an impediment if
> >you're working on projects where this is acceptable.
> >
> >> 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.
> >
> >I certainly hope when you are writing code that you explain your changes
> >somewhere.  I know some people who use pull requests prefer to do so in the pull
> >request rather than the commit message, but I for one would never accept a
> >change that doesn't contain some sort of explanation about why it's valuable or
> >relevant somewhere.  I am, unfortunately, not omniscient, so I need people to
> >communicate their intentions and decisions to me, and the best way to do that is
> >with words.
> >
> >I should also point out that the GitHub UI is specifically designed to show the
> >commit summary in the history view, so GitHub intends for you to write at least
> >one line of helpful text (the summary) in this context.
> >
> >Overall, I don't believe your proposal is likely to gain traction here for the reasons I
> >mentioned above, and I personally don't support it.
> 
> The commit message is an essential part of why a change was made, in particular for forensics when something goes wrong, or when you are trying to figure out why you did something. Without a commit message, you are saying, "yeah, ok, something happened." It's up there with reporting a bug saying, "It doesn't work", with no additional details - I have customers who do that, and it is not helpful. To be harsh about it, if someone commits something with no or a useless message, I will reject the change with impunity. Not explaining yourself is not helpful to those who come after. It's up there with "Why did you not document your code, when you used single letter variables and strung the whole program on one line because C (or APL) allows it," with an answer along the lines of "Any decent developer should be able to figure out the code." Sorry, but I feel very strongly on the subject that this is not a good idea. If you want to put junk in your commit, that is your business, but expect a
>   significant segment of the population looking at your repo on GitHub to judge harshly. This sounds more like "I don't want to use a version control system, but I have to for some reason, like HR metrics." I know I am being harsh on this, and I apologize in advance for it if I offended anyone, but I would want a way to disable (potentially at build time) this if it ever went forward.

There is nothing stopping you using '.' as the commit message which is
as informative as when it is empty. Hence this enforcement of non-empty
commit message does not serve the stated purpose.

Sure, if you are merging someone's pull request you can enforce that the
changes are intelliginle by human review but that's not something git
can do automatically.

Also I have an auto-generated git repository of web pages in which every
single commit message is the same. It is not empty because I was too
lazy to figure out how to do that but the effective information value is
the same. And it's in git because the publication system uses git as
backend so there it goes.

Thanks

Michal

Re: Make commit messages optional

[Tao Klerks]

On Sat, Apr 9, 2022 at 1:32 PM Michal Suchánek <msuchanek@suse.de> wrote:
>
> On Fri, Apr 08, 2022 at 07:32:03PM -0400, rsbecker@nexbridge.com wrote:
> > On April 8, 2022 6:30 PM, brian m. carlson wrote:
> > >On 2022-04-08 at 03:35:04, 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 want to encourage good software engineering practices.
> > >
[...]
> > >
> > >Users who want this behaviour can use --allow-empty-message or create an alias
> > >with that option.  The functionality already exists.  I use aliases extensively in my
> > >development and I know others do as well, so this shouldn't be an impediment if
> > >you're working on projects where this is acceptable.
> > >
[...]
>
> There is nothing stopping you using '.' as the commit message which is
> as informative as when it is empty. Hence this enforcement of non-empty
> commit message does not serve the stated purpose.

My apologies if this proposal has already been made in this or prior
discussions - the list server and gmail are having another
disagreement, so I think I'm a few hours out of date.

I believe the main argument *for* allowing empty commit messages by
default is "we shouldn't make it hard to do what you want to do, if
you can fix it later", 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".

In that sense, allowing people to create empty commit messages when
they shouldn't, is often "trapping" them into a commit history that is
less valuable (or even acceptable) than they might otherwise have
achieved.

While I therefore disagree with Aevar's proposal to "allow empty, and
advise", I do think the notion of giving advice makes perfect sense -
let's do it the other way around, with an advice message something
like:

---
Empty commit messages aren't normally allowed, as they reduce the
understandability of the commit history. If you do need to create a
commit with an empty message, you can do so by providing the
'--allow-empty-message' argument to 'git commit'.
---

Has this already been considered/discussed? Would it meet the
objectives of those folks saying "the rejection of empty messages
wasted my time", while also keeping the spirit of "we should make it
easy to do the right thing and harder to do the wrong thing,
especially for beginners"?

Thanks,
Tao

RE: Make commit messages optional

[rsbecker]

On April 10, 2022 10:00 AM, Tao Klerks wrote:
>To: Michal Suchánek <msuchanek@suse.de>
>Cc: rsbecker@nexbridge.com; brian m. carlson <sandals@crustytoothpaste.net>;
>jurgen_gjoncari@icloud.com; git@vger.kernel.org
>Subject: Re: Make commit messages optional
>
>On Sat, Apr 9, 2022 at 1:32 PM Michal Suchánek <msuchanek@suse.de> wrote:
>>
>> On Fri, Apr 08, 2022 at 07:32:03PM -0400, rsbecker@nexbridge.com wrote:
>> > On April 8, 2022 6:30 PM, brian m. carlson wrote:
>> > >On 2022-04-08 at 03:35:04, 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 want to encourage good software engineering practices.
>> > >
>[...]
>> > >
>> > >Users who want this behaviour can use --allow-empty-message or
>> > >create an alias with that option.  The functionality already
>> > >exists.  I use aliases extensively in my development and I know
>> > >others do as well, so this shouldn't be an impediment if you're working on
>projects where this is acceptable.
>> > >
>[...]
>>
>> There is nothing stopping you using '.' as the commit message which is
>> as informative as when it is empty. Hence this enforcement of
>> non-empty commit message does not serve the stated purpose.
>
>My apologies if this proposal has already been made in this or prior discussions -
>the list server and gmail are having another disagreement, so I think I'm a few
>hours out of date.
>
>I believe the main argument *for* allowing empty commit messages by default is
>"we shouldn't make it hard to do what you want to do, if you can fix it later", 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".

Adding commit messages has been part of SCM systems since virtually the beginning, at least on UNIX in the early 1970 and likely before. Adding a simple commit message is not onerous or difficult. "Fixing it later" will require the commit and any signature you put on at the time is lost. You also invalidate any signatures more recent in history. This does not corrupt your repo, but it does reduce its value. If you insist on doing this, use a single non-breaking space symbol in the -m option, which you can script or alias. Note that none of that will work on any git clients anyway. 

The main argument against is that this violates the basic principles of a well managed DevSecOps environment that requires who, what, where, when, why for every change, not just the ones you publish. The key point here of having comments in commits is that it allows organizations to pull in projects like OpenSSL that ends up in production and must have the accountability for the installation to be allowed. Otherwise, just give up on the concept of Open-Source because corporate auditors will reject any request to use your project. You will never get into a PCI environment without a full set of commit comments, not just the Pull Requests.

Granted my requirements come from regulated industries around the globe, and if you are making toys, so be it. My teams are making production-hardened applications.

>In that sense, allowing people to create empty commit messages when they
>shouldn't, is often "trapping" them into a commit history that is less valuable (or
>even acceptable) than they might otherwise have achieved.
>
>While I therefore disagree with Aevar's proposal to "allow empty, and advise", I do
>think the notion of giving advice makes perfect sense - let's do it the other way
>around, with an advice message something
>like:
>
>---
>Empty commit messages aren't normally allowed, as they reduce the
>understandability of the commit history. If you do need to create a commit with an
>empty message, you can do so by providing the '--allow-empty-message'
>argument to 'git commit'.
>---
>
>Has this already been considered/discussed? Would it meet the objectives of
>those folks saying "the rejection of empty messages wasted my time", while also
>keeping the spirit of "we should make it easy to do the right thing and harder to do
>the wrong thing, especially for beginners"?

I am not personally going to be convinced of any of this - forgive me but, I think this reduces git's value and credibility as the leading SCM solution on the planet (and off) and see no justification for enabling comment-less repositories other than laziness. Even if that were the case, it is grounds for termination in my company and most of my customers to deliberately bypass audit practices, so if git moves forward with this, we might have to move elsewhere.
--Randall

RE: Make commit messages optional

[rsbecker]

On April 10, 2022 11:00 AM, I wrote:
>On April 10, 2022 10:00 AM, Tao Klerks wrote:
>>To: Michal Suchánek <msuchanek@suse.de>
>>Cc: rsbecker@nexbridge.com; brian m. carlson
>><sandals@crustytoothpaste.net>; jurgen_gjoncari@icloud.com;
>>git@vger.kernel.org
>>Subject: Re: Make commit messages optional
>>
>>On Sat, Apr 9, 2022 at 1:32 PM Michal Suchánek <msuchanek@suse.de> wrote:
>>>
>>> On Fri, Apr 08, 2022 at 07:32:03PM -0400, rsbecker@nexbridge.com wrote:
>>> > On April 8, 2022 6:30 PM, brian m. carlson wrote:
>>> > >On 2022-04-08 at 03:35:04, 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 want to encourage good software engineering practices.
>>> > >
>>[...]
>>> > >
>>> > >Users who want this behaviour can use --allow-empty-message or
>>> > >create an alias with that option.  The functionality already
>>> > >exists.  I use aliases extensively in my development and I know
>>> > >others do as well, so this shouldn't be an impediment if you're
>>> > >working on
>>projects where this is acceptable.
>>> > >
>>[...]
>>>
>>> There is nothing stopping you using '.' as the commit message which
>>> is as informative as when it is empty. Hence this enforcement of
>>> non-empty commit message does not serve the stated purpose.
>>
>>My apologies if this proposal has already been made in this or prior
>>discussions - the list server and gmail are having another
>>disagreement, so I think I'm a few hours out of date.
>>
>>I believe the main argument *for* allowing empty commit messages by
>>default is "we shouldn't make it hard to do what you want to do, if you
>>can fix it later", 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".
>
>Adding commit messages has been part of SCM systems since virtually the
>beginning, at least on UNIX in the early 1970 and likely before. Adding a simple
>commit message is not onerous or difficult. "Fixing it later" will require the commit
>and any signature you put on at the time is lost. You also invalidate any signatures
>more recent in history. This does not corrupt your repo, but it does reduce its
>value. If you insist on doing this, use a single non-breaking space symbol in the -m
>option, which you can script or alias. Note that none of that will work on any git
>clients anyway.
>
>The main argument against is that this violates the basic principles of a well
>managed DevSecOps environment that requires who, what, where, when, why
>for every change, not just the ones you publish. The key point here of having
>comments in commits is that it allows organizations to pull in projects like OpenSSL
>that ends up in production and must have the accountability for the installation to
>be allowed. Otherwise, just give up on the concept of Open-Source because
>corporate auditors will reject any request to use your project. You will never get
>into a PCI environment without a full set of commit comments, not just the Pull
>Requests.
>
>Granted my requirements come from regulated industries around the globe, and
>if you are making toys, so be it. My teams are making production-hardened
>applications.
>
>>In that sense, allowing people to create empty commit messages when
>>they shouldn't, is often "trapping" them into a commit history that is
>>less valuable (or even acceptable) than they might otherwise have achieved.
>>
>>While I therefore disagree with Aevar's proposal to "allow empty, and
>>advise", I do think the notion of giving advice makes perfect sense -
>>let's do it the other way around, with an advice message something
>>like:
>>
>>---
>>Empty commit messages aren't normally allowed, as they reduce the
>>understandability of the commit history. If you do need to create a
>>commit with an empty message, you can do so by providing the '--allow-empty-
>message'
>>argument to 'git commit'.
>>---
>>
>>Has this already been considered/discussed? Would it meet the
>>objectives of those folks saying "the rejection of empty messages
>>wasted my time", while also keeping the spirit of "we should make it
>>easy to do the right thing and harder to do the wrong thing, especially for
>beginners"?
>
>I am not personally going to be convinced of any of this - forgive me but, I think
>this reduces git's value and credibility as the leading SCM solution on the planet
>(and off) and see no justification for enabling comment-less repositories other
>than laziness. Even if that were the case, it is grounds for termination in my
>company and most of my customers to deliberately bypass audit practices, so if git
>moves forward with this, we might have to move elsewhere.

And I still don't get why the --allow-empty-message is not sufficient to meet your use case. git supports what is being requested already, not that it is allowed where I am. Are we talking about setting --allow-empty-message as the default? That is a major behavioural change. You could create a git command alias to always specify this option. So what is the point of this?

Re: Make commit messages optional

[Tao Klerks]

On Sun, Apr 10, 2022 at 5:18 PM <rsbecker@nexbridge.com> wrote:
> On April 10, 2022 11:00 AM, I wrote:
> >On April 10, 2022 10:00 AM, Tao Klerks wrote:
> >
> >The main argument against is that this violates the basic principles of a well
> >managed DevSecOps environment that requires who, what, where, when, why
> >for every change, not just the ones you publish. The key point here of having
> >comments in commits is that it allows organizations to pull in projects like OpenSSL
> >that ends up in production and must have the accountability for the installation to
> >be allowed. Otherwise, just give up on the concept of Open-Source because
> >corporate auditors will reject any request to use your project. You will never get
> >into a PCI environment without a full set of commit comments, not just the Pull
> >Requests.

I don't understand your point here. Allowing empty commit messages, as
well as near-empty commit messages, is already a part of the git
ecosystem. Git itself does not, and could never, validate the
value/meaningfulness of any commit messages. DevSecOps, corporate
compliance, accountability, auditability - these are all useful and
necessary concepts, but meeting their requirements is not the business
of a client that millions of users use to do their daily work - it is
instead the business of secured server environments (that you might
want to push to), auditors, software supply chain management software,
etc.

Obviously your users (the ones that are expected to meet certain
requirements) should be discouraged or (more likely) prevented from
pushing messageless commits to the branches/environments that carry
auditability requirements; I'm guessing they probably also need to
have references to other systems (eg ticketing systems) to provide an
external "rationale" audit, GPG signature, ACLs and other things that
are simply not the business of the client.

I agree it would be a mistake to make it easier for such users (or any
users, really) to *accidentally* commit something without a message,
and then find themselves in a not-always-obvious "now I need to change
the past" situation.

> >
> >Granted my requirements come from regulated industries around the globe, and
> >if you are making toys, so be it. My teams are making production-hardened
> >applications.

No amount of "hardening" the client that people run on their own
machines will improve the security of *your* applications in any way.
All the problems you describe involve *server* security. Whether other
people choose to use the client to make toys, or art, or banking
software, or git itself... is their business? The implication that the
use of git in "serious industries" should make it worse for other
users (such as toymakers) is, I believe, unhelpful at best.

> >
> >>In that sense, allowing people to create empty commit messages when
> >>they shouldn't, is often "trapping" them into a commit history that is
> >>less valuable (or even acceptable) than they might otherwise have achieved.
> >>
> >>While I therefore disagree with Aevar's proposal to "allow empty, and
> >>advise", I do think the notion of giving advice makes perfect sense -
> >>let's do it the other way around, with an advice message something
> >>like:
> >>
> >>---
> >>Empty commit messages aren't normally allowed, as they reduce the
> >>understandability of the commit history. If you do need to create a
> >>commit with an empty message, you can do so by providing the '--allow-empty-
> >message'
> >>argument to 'git commit'.
> >>---
> >>
> >>Has this already been considered/discussed? Would it meet the
> >>objectives of those folks saying "the rejection of empty messages
> >>wasted my time", while also keeping the spirit of "we should make it
> >>easy to do the right thing and harder to do the wrong thing, especially for
> >beginners"?
> >
> >I am not personally going to be convinced of any of this - forgive me but, I think
> >this reduces git's value and credibility as the leading SCM solution on the planet
> >(and off) and see no justification for enabling comment-less repositories other
> >than laziness. Even if that were the case, it is grounds for termination in my
> >company and most of my customers to deliberately bypass audit practices, so if git
> >moves forward with this, we might have to move elsewhere.

Given your earlier comments, I'm not sure I understand the "this"
you're not going to be convinced by or about. What I was proposing,
and maybe I did a terrible job of it, is to *not* change the behavior
of the client in any significant way, but rather add some new advice
(which, like any git advice, can be turned off, eg by a corporate git
installer), which would show alongside the current "Aborting commit
due to empty commit message." error.

The exact text of that advice would obviously need to be carefully
considered, but I would expect it to say something like "committing
without a message is typically a mistake (and might prevent you from
pushing to the server later), but if you really want or need to, you
can use the --allow-empty-message option".

The point of this advice would be to clarify the existence of the
"--allow-empty-message" behavior (and reduce the incidence of "stupid"
commit messages like single periods), *without* in any way increasing
the incidence of *accidental* submission without a commit message.

>
> And I still don't get why the --allow-empty-message is not sufficient to meet your use case. git supports what is being requested already, not that it is allowed where I am. Are we talking about setting --allow-empty-message as the default? That is a major behavioural change. You could create a git command alias to always specify this option. So what is the point of this?
>

My proposal is that it absolutely is enough, functionally - but the
abundance of "we should change something" concerns in this thread and
elsewhere suggest, to me, that it might not be sufficiently
discoverable; hence the "advice" proposal.

Re: Make commit messages optional

[Jonathan Nieder]

Hi,

Tao Klerks wrote:
> On Sun, Apr 10, 2022 at 5:18 PM <rsbecker@nexbridge.com> wrote:

>> And I still don't get why the --allow-empty-message is not
>> sufficient to meet your use case. git supports what is being
>> requested already, not that it is allowed where I am. Are we
>> talking about setting --allow-empty-message as the default? That is
>> a major behavioural change. You could create a git command alias to
>> always specify this option. So what is the point of this?
>>
>
> My proposal is that it absolutely is enough, functionally - but the
> abundance of "we should change something" concerns in this thread and
> elsewhere suggest, to me, that it might not be sufficiently
> discoverable; hence the "advice" proposal.

Thanks for this point.  I find it to be a very reasonable one.  I'd be
happy to review a patch adding an advice item when people use options
like '-m ""'.

Sincerely,
Jonathan

Re: Make commit messages optional

[demerphq]

On Mon, 11 Apr 2022 at 09:27, <rsbecker@nexbridge.com> wrote:
>
> On April 10, 2022 10:00 AM, Tao Klerks wrote:
> >To: Michal Suchánek <msuchanek@suse.de>
> >Cc: rsbecker@nexbridge.com; brian m. carlson <sandals@crustytoothpaste.net>;
> >jurgen_gjoncari@icloud.com; git@vger.kernel.org
> >Subject: Re: Make commit messages optional
> >
> >On Sat, Apr 9, 2022 at 1:32 PM Michal Suchánek <msuchanek@suse.de> wrote:
> >>
> >> On Fri, Apr 08, 2022 at 07:32:03PM -0400, rsbecker@nexbridge.com wrote:
> >> > On April 8, 2022 6:30 PM, brian m. carlson wrote:
> >> > >On 2022-04-08 at 03:35:04, 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 want to encourage good software engineering practices.
> >> > >
> >[...]
> >> > >
> >> > >Users who want this behaviour can use --allow-empty-message or
> >> > >create an alias with that option.  The functionality already
> >> > >exists.  I use aliases extensively in my development and I know
> >> > >others do as well, so this shouldn't be an impediment if you're working on
> >projects where this is acceptable.
> >> > >
> >[...]
> >>
> >> There is nothing stopping you using '.' as the commit message which is
> >> as informative as when it is empty. Hence this enforcement of
> >> non-empty commit message does not serve the stated purpose.
> >
> >My apologies if this proposal has already been made in this or prior discussions -
> >the list server and gmail are having another disagreement, so I think I'm a few
> >hours out of date.
> >
> >I believe the main argument *for* allowing empty commit messages by default is
> >"we shouldn't make it hard to do what you want to do, if you can fix it later", 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".
>
> Adding commit messages has been part of SCM systems since virtually the beginning, at least on UNIX in the early 1970 and likely before. Adding a simple commit message is not onerous or difficult. "Fixing it later" will require the commit and any signature you put on at the time is lost. You also invalidate any signatures more recent in history. This does not corrupt your repo, but it does reduce its value. If you insist on doing this, use a single non-breaking space symbol in the -m option, which you can script or alias. Note that none of that will work on any git clients anyway.
>
> The main argument against is that this violates the basic principles of a well managed DevSecOps environment that requires who, what, where, when, why for every change, not just the ones you publish. The key point here of having comments in commits is that it allows organizations to pull in projects like OpenSSL that ends up in production and must have the accountability for the installation to be allowed. Otherwise, just give up on the concept of Open-Source because corporate auditors will reject any request to use your project. You will never get into a PCI environment without a full set of commit comments, not just the Pull Requests.
>
> Granted my requirements come from regulated industries around the globe, and if you are making toys, so be it. My teams are making production-hardened applications.

First off, git already allows empty commit messages. If you aren't
already validating the commits that are being pushed to your central
repo then you are already allowing commits with no commit message.
Have your auditors noticed or complained?

Second, I think you really did not understand Avar's point. Let me try
to restate it in simple terms.

One of the things that separates git from most other SCM's, especially
legacy SCM's, is that it separates the act of creating a commit and
that of pushing it to the upstream repo.

Advanced git users make very heavy use of git rebase --interactive and
similar tools to modify, reorder, reword, merge, split, and otherwise
munge the commits they have created *locally* before they push them
upstream.

What Avar is saying is that there really is no reason to require a
commit message *locally* when a user is likely to be doing such
activities. Instead what should happen is that the upstream should be
taught to refuse commits pushed to it which do not comply with
whatever audit rules you wish to enforce.

For instance, your audit rules could require that every commit
includes verbiage like "I understand that I am responsible for the
content of this commit, I understand the rules which this commit must
comply with, and that I will be held accountable for any deviations
from those rules."  Would there be any point in enforcing this locally
on commits which are intended to be thrown away and squashed before
they are sent? I would say no, for a bunch of reasons, not least being
that preventative controls cannot be relied on in an uncontrolled
environment like someone's laptop, and if you weren't *also*
validating those rules upstream then your protections would be as
secure as using client side JS to validate entry to a web-form - that
is not secure *at all*.

The only way to be really sure that no commits end up in your master
repository that do not comply with your rules is to validate the rules
on push to the master repository, and to reject any attempt to push
commits which do not comply.

I often create dozens of tiny commits with the words "WIP" (work in
progress), which I then later reorder, and then squash together into a
nice logical and well explained series of commits, at which time I
give them nice detailed commit messages. Requiring me to type 'WIP"
every time is really unnecessary and not particularly helpful to
anyone. I dont use --allow-empty-mesage because -m'WIP' is less to
type than --allow-empty-message, but that is besides the point 'WIP'
is not an acceptable commit message to an auditor and should not be
merged.

> >In that sense, allowing people to create empty commit messages when they
> >shouldn't, is often "trapping" them into a commit history that is less valuable (or
> >even acceptable) than they might otherwise have achieved.
> >
> >While I therefore disagree with Aevar's proposal to "allow empty, and advise", I do
> >think the notion of giving advice makes perfect sense - let's do it the other way
> >around, with an advice message something
> >like:
> >
> >---
> >Empty commit messages aren't normally allowed, as they reduce the
> >understandability of the commit history. If you do need to create a commit with an
> >empty message, you can do so by providing the '--allow-empty-message'
> >argument to 'git commit'.
> >---
> >
> >Has this already been considered/discussed? Would it meet the objectives of
> >those folks saying "the rejection of empty messages wasted my time", while also
> >keeping the spirit of "we should make it easy to do the right thing and harder to do
> >the wrong thing, especially for beginners"?
>

> I am not personally going to be convinced of any of this - forgive me but, I think this reduces git's value and credibility as the leading SCM solution on the planet (and off) and see no justification for enabling comment-less repositories other than laziness. Even if that were the case, it is grounds for termination in my company and most of my customers to deliberately bypass audit practices, so if git moves forward with this, we might have to move elsewhere.

With respect I dont think you actually understand how the audit
process works; a developers laptop is not a controlled environment
which is trustable by an auditor.  As has already been stated by
several posters git *already* allows empty commits messages, and if
you are not implementing controls in your master repository that all
pushed commits to controlled branches comply with your rules then you
*already* have a vector to allow such commits into your master
repository and you are probably not in compliance with your auditors
requirements.

Preventive controls can *only* be effective and relied on when
executed inside of a completely controlled context. A dev's local
working context is NOT a completely controlled context. Think about
it, they have a compiler on hand, they can do anything their skills
allow them to do. Even if git did not *already* allow empty messages a
suitably skilled dev could always hack git to allow them. If you did
not have preventive controls upstream at the master repo you are using
for audit controls then whatever policy might be baked into the
current git client is moot. Someone could hand roll a commit that
violated them and send them using something other than git. This is
all just software after all.

If you are concerned about the audit practices that your company needs
to comply with then you should be looking at server-side hooks
(pre-receive hooks) in your master repository, not client side rules
in the git executable your devs use, those rules are ineffective and
ultimately should be deemed unreliable by any competent auditor.

Note that most auditors do *not* require every control to be
preventive, they strongly prefer preventive controls for obvious
reasons, but they also understand that not every rule can be
implemented as a preventive control, so they also allow *detective*
controls, eg, a daily report showing that all commits in the master
repo comply with their requirements. You may be able to work with your
auditor to implement detective controls instead. However, given that
git absolutely does have the ability to implement upstream preventive
controls it seems that you should focus your concerns there.

BTW, I am saying this as someone who has had extensive experience
working with auditors on git controls for many years. Nothing you do
client side is relevant to the auditor and if it is you should hire a
new auditor yours is not competent. If you dont verify things in a
controlled environment then you haven't controlled things at all.

Consider if one of your devs writes a commit with an empty message and
that commit is never pushed upstream have they broken a rule? I bet
not. Consider a common audit policy of requiring "two head approval",
eg two people need to approve that a commit is reasonable to be
merged. In corporate context most auditors will consider the author of
the commit to be one, head, but usually some upstream tool, say github
or gitlab, is responsible for managing the approval process for the
second head. Since every commit created locally cannot have two
approvers at its time of creation this means that every commit is
created in violation of the audit rules.  But auditors don't have any
concern with this because they know that the real concern is ensuring
a robust controls process is applied before that commit can be pushed
upstream and merged into the central repository.

So with respect, I think you really don't understand how the audit
process works and you really haven't thought through your concern.
Whatever happens locally on the developers box is immaterial to the
auditor, they only care about the upstream master repo. Heck they
might not even care about that and only care about the commits that
are actually compiled or deployed to a production environment. So you
could have your preventive controls in the build stage and not in the
SCM at all. But most companies would prefer to implement such controls
relatively close to the person/subject being controlled and would
prefer to see proper well implemented and strong preventive controls
in your master repo's pre-receive hooks.

In my former job we used a combination of preventive and detective
controls. It is a web shop where a deployment could happen at any
time, and some controls can interfere with outage resolution and
fire-fighting, so we had a magic phrase that could be used to bypass
the preventive controls but would trigger a detective control to
review what happened and ensure that it was all above board. I was one
of the people who would have to review the use of the bypass. No
auditor had any issue with this. Auditors are usually pretty
reasonable people.

cheers,
Yves

-- 
perl -Mre=debug -e "/just|another|perl|hacker/"

RE: Make commit messages optional

[rsbecker]

On April 11, 2022 5:05 AM, demerphq wrote:
>On Mon, 11 Apr 2022 at 09:27, <rsbecker@nexbridge.com> wrote:
>>
>> On April 10, 2022 10:00 AM, Tao Klerks wrote:
>> >To: Michal Suchánek <msuchanek@suse.de>
>> >Cc: rsbecker@nexbridge.com; brian m. carlson
>> ><sandals@crustytoothpaste.net>; jurgen_gjoncari@icloud.com;
>> >git@vger.kernel.org
>> >Subject: Re: Make commit messages optional
>> >
>> >On Sat, Apr 9, 2022 at 1:32 PM Michal Suchánek <msuchanek@suse.de> wrote:
>> >>
>> >> On Fri, Apr 08, 2022 at 07:32:03PM -0400, rsbecker@nexbridge.com wrote:
>> >> > On April 8, 2022 6:30 PM, brian m. carlson wrote:
>> >> > >On 2022-04-08 at 03:35:04, 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 want to encourage good software engineering practices.
>> >> > >
>> >[...]
>> >> > >
>> >> > >Users who want this behaviour can use --allow-empty-message or
>> >> > >create an alias with that option.  The functionality already
>> >> > >exists.  I use aliases extensively in my development and I know
>> >> > >others do as well, so this shouldn't be an impediment if you're
>> >> > >working on
>> >projects where this is acceptable.
>> >> > >
>> >[...]
>> >>
>> >> There is nothing stopping you using '.' as the commit message which
>> >> is as informative as when it is empty. Hence this enforcement of
>> >> non-empty commit message does not serve the stated purpose.
>> >
>> >My apologies if this proposal has already been made in this or prior
>> >discussions - the list server and gmail are having another
>> >disagreement, so I think I'm a few hours out of date.
>> >
>> >I believe the main argument *for* allowing empty commit messages by
>> >default is "we shouldn't make it hard to do what you want to do, if
>> >you can fix it later", 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".
>>
>> Adding commit messages has been part of SCM systems since virtually the
>beginning, at least on UNIX in the early 1970 and likely before. Adding a simple
>commit message is not onerous or difficult. "Fixing it later" will require the commit
>and any signature you put on at the time is lost. You also invalidate any signatures
>more recent in history. This does not corrupt your repo, but it does reduce its
>value. If you insist on doing this, use a single non-breaking space symbol in the -m
>option, which you can script or alias. Note that none of that will work on any git
>clients anyway.
>>
>> The main argument against is that this violates the basic principles of a well
>managed DevSecOps environment that requires who, what, where, when, why
>for every change, not just the ones you publish. The key point here of having
>comments in commits is that it allows organizations to pull in projects like OpenSSL
>that ends up in production and must have the accountability for the installation to
>be allowed. Otherwise, just give up on the concept of Open-Source because
>corporate auditors will reject any request to use your project. You will never get
>into a PCI environment without a full set of commit comments, not just the Pull
>Requests.
>>
>> Granted my requirements come from regulated industries around the globe,
>and if you are making toys, so be it. My teams are making production-hardened
>applications.
>
>First off, git already allows empty commit messages. If you aren't already
>validating the commits that are being pushed to your central repo then you are
>already allowing commits with no commit message.
>Have your auditors noticed or complained?
>
>Second, I think you really did not understand Avar's point. Let me try to restate it
>in simple terms.
>
>One of the things that separates git from most other SCM's, especially legacy
>SCM's, is that it separates the act of creating a commit and that of pushing it to the
>upstream repo.
>
>Advanced git users make very heavy use of git rebase --interactive and similar
>tools to modify, reorder, reword, merge, split, and otherwise munge the commits
>they have created *locally* before they push them upstream.
>
>What Avar is saying is that there really is no reason to require a commit message
>*locally* when a user is likely to be doing such activities. Instead what should
>happen is that the upstream should be taught to refuse commits pushed to it
>which do not comply with whatever audit rules you wish to enforce.
>
>For instance, your audit rules could require that every commit includes verbiage
>like "I understand that I am responsible for the content of this commit, I
>understand the rules which this commit must comply with, and that I will be held
>accountable for any deviations from those rules."  Would there be any point in
>enforcing this locally on commits which are intended to be thrown away and
>squashed before they are sent? I would say no, for a bunch of reasons, not least
>being that preventative controls cannot be relied on in an uncontrolled
>environment like someone's laptop, and if you weren't *also* validating those
>rules upstream then your protections would be as secure as using client side JS to
>validate entry to a web-form - that is not secure *at all*.
>
>The only way to be really sure that no commits end up in your master repository
>that do not comply with your rules is to validate the rules on push to the master
>repository, and to reject any attempt to push commits which do not comply.
>
>I often create dozens of tiny commits with the words "WIP" (work in progress),
>which I then later reorder, and then squash together into a nice logical and well
>explained series of commits, at which time I give them nice detailed commit
>messages. Requiring me to type 'WIP"
>every time is really unnecessary and not particularly helpful to anyone. I dont use -
>-allow-empty-mesage because -m'WIP' is less to type than --allow-empty-
>message, but that is besides the point 'WIP'
>is not an acceptable commit message to an auditor and should not be merged.
>
>> >In that sense, allowing people to create empty commit messages when
>> >they shouldn't, is often "trapping" them into a commit history that
>> >is less valuable (or even acceptable) than they might otherwise have achieved.
>> >
>> >While I therefore disagree with Aevar's proposal to "allow empty, and
>> >advise", I do think the notion of giving advice makes perfect sense -
>> >let's do it the other way around, with an advice message something
>> >like:
>> >
>> >---
>> >Empty commit messages aren't normally allowed, as they reduce the
>> >understandability of the commit history. If you do need to create a
>> >commit with an empty message, you can do so by providing the '--allow-
>empty-message'
>> >argument to 'git commit'.
>> >---
>> >
>> >Has this already been considered/discussed? Would it meet the
>> >objectives of those folks saying "the rejection of empty messages
>> >wasted my time", while also keeping the spirit of "we should make it
>> >easy to do the right thing and harder to do the wrong thing, especially for
>beginners"?
>>
>
>> I am not personally going to be convinced of any of this - forgive me but, I think
>this reduces git's value and credibility as the leading SCM solution on the planet
>(and off) and see no justification for enabling comment-less repositories other
>than laziness. Even if that were the case, it is grounds for termination in my
>company and most of my customers to deliberately bypass audit practices, so if git
>moves forward with this, we might have to move elsewhere.
>
>With respect I dont think you actually understand how the audit process works; a
>developers laptop is not a controlled environment which is trustable by an auditor.
>As has already been stated by several posters git *already* allows empty commits
>messages, and if you are not implementing controls in your master repository that
>all pushed commits to controlled branches comply with your rules then you
>*already* have a vector to allow such commits into your master repository and
>you are probably not in compliance with your auditors requirements.
>
>Preventive controls can *only* be effective and relied on when executed inside of
>a completely controlled context. A dev's local working context is NOT a completely
>controlled context. Think about it, they have a compiler on hand, they can do
>anything their skills allow them to do. Even if git did not *already* allow empty
>messages a suitably skilled dev could always hack git to allow them. If you did not
>have preventive controls upstream at the master repo you are using for audit
>controls then whatever policy might be baked into the current git client is moot.
>Someone could hand roll a commit that violated them and send them using
>something other than git. This is all just software after all.
>
>If you are concerned about the audit practices that your company needs to comply
>with then you should be looking at server-side hooks (pre-receive hooks) in your
>master repository, not client side rules in the git executable your devs use, those
>rules are ineffective and ultimately should be deemed unreliable by any
>competent auditor.
>
>Note that most auditors do *not* require every control to be preventive, they
>strongly prefer preventive controls for obvious reasons, but they also understand
>that not every rule can be implemented as a preventive control, so they also allow
>*detective* controls, eg, a daily report showing that all commits in the master
>repo comply with their requirements. You may be able to work with your auditor
>to implement detective controls instead. However, given that git absolutely does
>have the ability to implement upstream preventive controls it seems that you
>should focus your concerns there.
>
>BTW, I am saying this as someone who has had extensive experience working with
>auditors on git controls for many years. Nothing you do client side is relevant to
>the auditor and if it is you should hire a new auditor yours is not competent. If you
>dont verify things in a controlled environment then you haven't controlled things
>at all.
>
>Consider if one of your devs writes a commit with an empty message and that
>commit is never pushed upstream have they broken a rule? I bet not. Consider a
>common audit policy of requiring "two head approval", eg two people need to
>approve that a commit is reasonable to be merged. In corporate context most
>auditors will consider the author of the commit to be one, head, but usually some
>upstream tool, say github or gitlab, is responsible for managing the approval
>process for the second head. Since every commit created locally cannot have two
>approvers at its time of creation this means that every commit is created in
>violation of the audit rules.  But auditors don't have any concern with this because
>they know that the real concern is ensuring a robust controls process is applied
>before that commit can be pushed upstream and merged into the central
>repository.
>
>So with respect, I think you really don't understand how the audit process works
>and you really haven't thought through your concern.
>Whatever happens locally on the developers box is immaterial to the auditor, they
>only care about the upstream master repo. Heck they might not even care about
>that and only care about the commits that are actually compiled or deployed to a
>production environment. So you could have your preventive controls in the build
>stage and not in the SCM at all. But most companies would prefer to implement
>such controls relatively close to the person/subject being controlled and would
>prefer to see proper well implemented and strong preventive controls in your
>master repo's pre-receive hooks.

I am going to bow out of this conversion since it has become personal and attacks my credibility in a manner that is offensive. You are obviously entitled to have your opinion but I would appreciate if you would keep this on the facts and use cases instead of saying of going with an ad hominem approach to the discussion that I do not understand this or that so my argument must be wrong. My experience is my own and you do not know me or what I do or with whom I work. Thank you for your critique.
--Randall

Re: Make commit messages optional

[Ævar Arnfjörð Bjarmason]

On Sun, Apr 10 2022, Tao Klerks wrote:

> On Sat, Apr 9, 2022 at 1:32 PM Michal Suchánek <msuchanek@suse.de> wrote:
>>
>> On Fri, Apr 08, 2022 at 07:32:03PM -0400, rsbecker@nexbridge.com wrote:
>> > On April 8, 2022 6:30 PM, brian m. carlson wrote:
>> > >On 2022-04-08 at 03:35:04, 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 want to encourage good software engineering practices.
>> > >
> [...]
>> > >
>> > >Users who want this behaviour can use --allow-empty-message or create an alias
>> > >with that option.  The functionality already exists.  I use aliases extensively in my
>> > >development and I know others do as well, so this shouldn't be an impediment if
>> > >you're working on projects where this is acceptable.
>> > >
> [...]
>>
>> There is nothing stopping you using '.' as the commit message which is
>> as informative as when it is empty. Hence this enforcement of non-empty
>> commit message does not serve the stated purpose.
>
> My apologies if this proposal has already been made in this or prior
> discussions - the list server and gmail are having another
> disagreement, so I think I'm a few hours out of date.
>
> I believe the main argument *for* allowing empty commit messages by
> default is "we shouldn't make it hard to do what you want to do, if
> you can fix it later",

Or don't fix it later, e.g. in the gist case mentioned in [1]. As shown
in [2] forcing the user to provide a message can serve to increase the
noise to signal ratio, in making it harder to distinguish those commits
where the author had nothing to say.

I have numerous local repos where I'd benefit from --allow-empty-message
by default (of course I can customize it, but habits etc). Now through
some combination of scripting and habits I've ended up with e.g.:

    git commit -mbump

These are things like my local (private) notes file, a repo that keeps
snapshots of E-Mails I send to the Git ML etc. Those things are newer
going to have meaningful commit messages.

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

I think it would be useful if those advocating for this behavior would
indicate whether or not some working solution of doing it in a different
place would address their concerns, whether or not we have patches ready
for that.

E.g. something that (if you have empty commit messages) would prompt you
to interactively rebase the to-be-pushed history or whatever.

Another thing that occurred to me after sending [1] was that perhaps
"repo size" would be good heuristic, we already have a fast estimation
of that for showing abbreviated commit OIDs.

That wouldn't do the right thing on e.g. large private git-annex repos,
but would serve to distinguish a "real, mid-size or large repo" like
git.git, redis.git, linux.git etc. from dotfiles, gists etc.
	
> In that sense, allowing people to create empty commit messages when
> they shouldn't, is often "trapping" them into a commit history that is
> less valuable (or even acceptable) than they might otherwise have
> achieved.

I agree with that if you s/allowing people to create empty/force people
to create non-empty/ :)

I think all the arguments in this thread (including mine) are ultimately
built on anecdotes, and I don't think that we can hope to get out of
that rut.

E.g. I've helped a lot of novice people with git (being the go-to "git
guy" at a past job), and one of *the most common* things I encountered
was users with some absolute mess of a working tree with large
outstanding changes, which ultimately came down to them being afraid to
commit it as it "wasn't ready".

So I really think anything we can do to break that particular pattern is
more helpful than not.

But am I absolutely confident that I'm right, and that these concerns
will outweigh other anecdotes brought up in this thread? No.

But what I am confident in saying is that tweaking the UX in this area
will have cost/benefits whatever you do, and I think that whatever
"side" one picks here the interesting arguments to be had is trying to
discuss and mitigate those costs.

> While I therefore disagree with Aevar's proposal to "allow empty, and
> advise", I do think the notion of giving advice makes perfect sense -
> let's do it the other way around, with an advice message something
> like:

Note that that's a pretty narrow reading of [1]. The main thrust of my
point was that we should consider moving this to "push" or "merge" time.

> ---
> Empty commit messages aren't normally allowed, as they reduce the
> understandability of the commit history. If you do need to create a
> commit with an empty message, you can do so by providing the
> '--allow-empty-message' argument to 'git commit'.
> ---
> Has this already been considered/discussed? Would it meet the
> objectives of those folks saying "the rejection of empty messages
> wasted my time", while also keeping the spirit of "we should make it
> easy to do the right thing and harder to do the wrong thing,
> especially for beginners"?

I think that's a lot worse than the status quo, at least now our
behavior just seems like a very basic safeguard, e.g.:
	
	$ git commit -a
	hint: Waiting for your editor to close the file... Waiting for Emacs...
	Aborting commit due to empty commit message.

There I opened my editor, saved the empty file that came up ("empty"
when adjusted for comments), and "git commit" aborted.

Even if I think we should make some version of "allow empty" the default
I think *that* particular thing should stay.

I.e. that's really helping a user to mitigate a genuine mistake,
particularly if something goes wrong with the external editor. I.e. I
think something like this would be sufficient (as in, it should
succeed):

    $ git commit -a --no-edit
    Aborting commit due to empty commit message.

All of those would be good cases to get feedback on, i.e. let's leave
aside the question of whether the UX should "encourage" and whether
--allow-empty-message should be the default, do the proponents of the
status quo think all of these are sensible:

    git commit -a # launches editor
    git commit -a -m"" # empty message
    git commit -a --no-edit # no editor

Aside from anything else I think --allow-empty-message for that last one
is rather silly, it's basically making the user say
--yes-i-know-the-default-messages-is-the-empty-message. Maybe it's
arguably in the case of a pre-commit hook & without --no-verify?

Anyway, that was a bit of a digression, sorry.

The reason I think it's "worse than the status quo" is that it takes us
from something that seems to be an overzelous CLI option check gone
wrong to actively recommending a "novice forever" UX pattern. I.e. the
"reduce the understandability of the commit history" etc. assumes or
implies that we won't have a "git rebase -i" before pushing.

1. https://lore.kernel.org/git/220408.86r167bxra.gmgdl@evledraar.gmail.com/
2. https://lore.kernel.org/git/220411.865ynfkj7r.gmgdl@evledraar.gmail.com/

Re: Make commit messages optional

[Tao Klerks]

On Mon, Apr 11, 2022 at 1:03 PM Ævar Arnfjörð Bjarmason
<avarab@gmail.com> wrote:
>
> E.g. something that (if you have empty commit messages) would prompt you
> to interactively rebase the to-be-pushed history or whatever.

Personally, I strive to recommend workflows where rebasing is not
necessary, and I believe that this is a better direction for git to go
in, rather than rebasing-by-default.

Rebasing is awesome, I use it all the time, it is definitely part of
the joy (my joy?) of using git - but again, the more we can design
workflows where rebasing is a private matter, the better the on-ramp
looks, I believe.

>
> Another thing that occurred to me after sending [1] was that perhaps
> "repo size" would be good heuristic, we already have a fast estimation
> of that for showing abbreviated commit OIDs.
>
> That wouldn't do the right thing on e.g. large private git-annex repos,
> but would serve to distinguish a "real, mid-size or large repo" like
> git.git, redis.git, linux.git etc. from dotfiles, gists etc.

I'm sorry, I didn't get it; are you proposing that empty commit
messages should be more acceptable in small repos, presumably on the
assumption that they are likely private?

>
> > In that sense, allowing people to create empty commit messages when
> > they shouldn't, is often "trapping" them into a commit history that is
> > less valuable (or even acceptable) than they might otherwise have
> > achieved.
>
> I agree with that if you s/allowing people to create empty/force people
> to create non-empty/ :)

At the risk of projecting my own experience too much, I'd like to
understand the assumptions in play: I assume that most people
committing in git end up doing so in the context of some process, some
organization, with the goal of eventually pushing the work "upstream",
to somewhere others will be able to evaluate and/or benefit from the
change. I assume that people using git as part of personal logging
systems, backup systems etc is far more rare, and that the mindset
associated with committing to most single-user private projects is
still "one day, I'll want to make use of that".

Given these assumptions, I personally believe that the cost to a new
user of having to figure out how to change a commit message (and not
fall afoul of the many risks changing the past introduces, eg
accidentally duplicating history via a "merge pull" after a rebase of
already-pushed commits), is higher than the risk of a user being
intimidated by the need to write a message and choosing to not write
(or commit) anything, rather than writing something silly.

All that said, I'll happily bow to the experience of my betters, of
which there are many already in this thread. My objective in joining
the discussion was only to point out that enhancing the
*discoverability* (of the empty-commit-message option) may allay
*some* of the sentiment behind this thread's initiation and popularity
without aggravating the counter-concerns raised.


>
> E.g. I've helped a lot of novice people with git (being the go-to "git
> guy" at a past job), and one of *the most common* things I encountered
> was users with some absolute mess of a working tree with large
> outstanding changes, which ultimately came down to them being afraid to
> commit it as it "wasn't ready".
>
> So I really think anything we can do to break that particular pattern is
> more helpful than not.

I can see how such a tendency may be aggravated by the need to set a
message, but I still don't believe the risk/reward of *more often
accidentally* creating commits without commit messages would be
favorable.

> But what I am confident in saying is that tweaking the UX in this area
> will have cost/benefits whatever you do, and I think that whatever
> "side" one picks here the interesting arguments to be had is trying to
> discuss and mitigate those costs.
>

+1

> > While I therefore disagree with Aevar's proposal to "allow empty, and
> > advise", I do think the notion of giving advice makes perfect sense -
> > let's do it the other way around, with an advice message something
> > like:
>
> Note that that's a pretty narrow reading of [1]. The main thrust of my
> point was that we should consider moving this to "push" or "merge" time.

My apologies for the misunderstanding and misrepresentation; as far as
I can tell I disagree with you on the desirability of push/merge-time
commit modification automation or advice, but I clearly did not
read/understand your proposal properly before paraphrasing it.

>
> > ---
> > Empty commit messages aren't normally allowed, as they reduce the
> > understandability of the commit history. If you do need to create a
> > commit with an empty message, you can do so by providing the
> > '--allow-empty-message' argument to 'git commit'.
> > ---
> > Has this already been considered/discussed? Would it meet the
> > objectives of those folks saying "the rejection of empty messages
> > wasted my time", while also keeping the spirit of "we should make it
> > easy to do the right thing and harder to do the wrong thing,
> > especially for beginners"?
>
> I think that's a lot worse than the status quo, at least now our
> behavior just seems like a very basic safeguard, e.g.:
>
>         $ git commit -a
>         hint: Waiting for your editor to close the file... Waiting for Emacs...
>         Aborting commit due to empty commit message.
>
> There I opened my editor, saved the empty file that came up ("empty"
> when adjusted for comments), and "git commit" aborted.
>
> Even if I think we should make some version of "allow empty" the default
> I think *that* particular thing should stay.

I don't really understand what you are saying is worse - the very idea
of accompanying the "Aborting commit due to empty commit message"
error with advice clarifying that you *can* in fact commit with an
empty message? Or the specifics of the message I proposed?

It looks like we agree that the current behavior of aborting the
commit when an editor is popped up and closed empty, is one that we
agree on, at least. I had not understood that from your initial "I
agree that we should do away with the check for the empty commit
message." response.

I assumed that at least some others in this thread intent on "not
changing the behavior" were reacting to the risk of *accidentally* or
"ignorantly" creating messageless commits, rather than advocating for
doing away with the --allow-empty-message option altogether.

>
> I.e. that's really helping a user to mitigate a genuine mistake,
> particularly if something goes wrong with the external editor. I.e. I
> think something like this would be sufficient (as in, it should
> succeed):
>
>     $ git commit -a --no-edit
>     Aborting commit due to empty commit message.

That seems very reasonable to me, fwiw - it's hard to see how you do
--no-edit by accident.

>
> All of those would be good cases to get feedback on, i.e. let's leave
> aside the question of whether the UX should "encourage" and whether
> --allow-empty-message should be the default, do the proponents of the
> status quo think all of these are sensible:
>
>     git commit -a # launches editor
Yes - I believe that interactively prompting the user for a message is
the right thing.

>     git commit -a -m"" # empty message
Yes - I believe that rejecting the empty message by default here is
still the right thing - there are many ways of doing this by accident,
I believe we should require a more explicit signal of intent before
accepting an empty message.

>     git commit -a --no-edit # no editor
No - I agree "--no-edit" seems like a clear enough signal of intent
that we shouldn't *also* require --allow-empty-message

>
> Aside from anything else I think --allow-empty-message for that last one
> is rather silly, it's basically making the user say
> --yes-i-know-the-default-messages-is-the-empty-message. Maybe it's
> arguably in the case of a pre-commit hook & without --no-verify?
>
> Anyway, that was a bit of a digression, sorry.
>

I don't believe it is a digression, at all. I think this thread could
head in a more productive direction if a series of specific measures
were proposed, each outlining what it hopes to achieve, and evaluated
each on their merits.

> The reason I think it's "worse than the status quo" is that it takes us
> from something that seems to be an overzelous CLI option check gone
> wrong to actively recommending a "novice forever" UX pattern. I.e. the
> "reduce the understandability of the commit history" etc. assumes or
> implies that we won't have a "git rebase -i" before pushing.
>

So, it sounds like you don't believe the discoverability of
"--allow-empty-message" is a significant concern, and the really
important question here, the one you were referring to when you
suggested to "do away with the check for the empty commit message",
was the behavior when an empty message is "more explicitly" passed in,
using the "--message" or "--file" options...?

Fwiw, I think those patterns still very easily allow for *accidental*
empty messages, and I would prefer to require a more explicit  signal
of intent, and I would have thought *some* reasonably-worded advice
would remove the "sting" of having to do something different from "-m
''". One other possibility I don't see discussed, is whether a
single-letter flag for "--allow-empty-message" (or "--no-edit" would
help. Several discussion participants noted they use garbage rather
than empty just to avoid typing so much...

Re: Make commit messages optional

[Junio C Hamano]

Tao Klerks <tao@klerks.biz> writes:

> Several discussion participants noted they use garbage rather
> than empty just to avoid typing so much...

It is a positive thing, isn't it?

If they consistently use greppable garbage, that may serve as even
better reminders that they need to revisit and clean them up later.

Re: Make commit messages optional

[Michal Suchánek]

On Mon, Apr 11, 2022 at 11:09:07AM -0700, Junio C Hamano wrote:
> Tao Klerks <tao@klerks.biz> writes:
> 
> > Several discussion participants noted they use garbage rather
> > than empty just to avoid typing so much...
> 
> It is a positive thing, isn't it?
> 
> If they consistently use greppable garbage, that may serve as even
> better reminders that they need to revisit and clean them up later.

Uhh, that'e very contrived argument.

Was that meant as a joke?

Maybe you forgot your smiley faces.

Thanks

Michal

Re: Make commit messages optional

[tytso]

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

Re: Make commit messages optional

[Ævar Arnfjörð Bjarmason]

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.

Re: Make commit messages optional

[Theodore Ts'o]

On Mon, Apr 11, 2022 at 10:10:23PM +0200, Ævar Arnfjörð Bjarmason wrote:
> 
> 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.

I would have thought it was painfully obvious that changing the
*default* is a ***terrible*** idea?

Is anyone other than the OP seriously promoting changing the default?

If someone wants to do something terrible to their own development
workflow (or if it actually makes sense for their workflow) we could
add some configuration, but if the question is changing the default,
my ppersonal opinion is, "Heck, no!"

   	  	     	    	      - Ted

Re: Make commit messages optional

[Ævar Arnfjörð Bjarmason]

On Thu, Apr 14 2022, Theodore Ts'o wrote:

> On Mon, Apr 11, 2022 at 10:10:23PM +0200, Ævar Arnfjörð Bjarmason wrote:
>> 
>> 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.
>
> I would have thought it was painfully obvious that changing the
> *default* is a ***terrible*** idea?
>
> Is anyone other than the OP seriously promoting changing the default?

Urm, yeah? I am, in the E-Mail upthread that replied to. The OP here is
jurgen_gjoncari@icloud.com.

> If someone wants to do something terrible to their own development
> workflow (or if it actually makes sense for their workflow) we could
> add some configuration, but if the question is changing the default,
> my ppersonal opinion is, "Heck, no!"

I think you're almost certainly correct that there's worthwhile things
we can catch with the current default.

I just suspect that we can do so much more effectively and encourage
more effectivey workflows by doing so at the point of propagation, not
commit.

Re: Make commit messages optional

[Junio C Hamano]

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

> On Thu, Apr 14 2022, Theodore Ts'o wrote:
>
>> I would have thought it was painfully obvious that changing the
>> *default* is a ***terrible*** idea?
>>
>> Is anyone other than the OP seriously promoting changing the default?
>
> Urm, yeah? I am, in the E-Mail upthread that replied to. The OP here is
> jurgen_gjoncari@icloud.com.

Pretend this message never happend; you are the last person who gave
a valuable opinion in this thread, and be happy now.

> ...
> I just suspect that we can do so much more effectively and encourage
> more effectivey workflows by doing so at the point of propagation, not
> commit.

We are talking about "git commit" Porcelain.  Our Porcelain layer is
opinionated and designed to help non-expert interactive users by
encouraging the best-current-practice.  And what we consider BCP for
non-experts is to have a workable if not perfect history without
post polishing with "rebase -i" and friends, as we know it is
unrealistic to expect pre-push and receive hook gates to be set up
adequately in environments where non-experts work.

Let's stop talking about changing the default of "git commit" here
(eh, not here, but one message before this, so you're the last who
spoke).  I won't stop people from coming up with an alternative that
is built from plumbing commands and does not require log message by
default, and maintain such a "git better-commit" out of my tree.

Thanks.