All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Mike McLean <stixmclean@googlemail.com>
Cc: "brian m. carlson" <sandals@crustytoothpaste.net>, git@vger.kernel.org
Subject: Re: Git Feature Request (Commit Message editing directly from interactive rebase control file)
Date: Wed, 23 Dec 2020 23:21:54 -0500	[thread overview]
Message-ID: <X+QXYhSnuIOdeeCv@mit.edu> (raw)
In-Reply-To: <CAM0jFOfA2HH9gC0RRX52NSEPGcsCg_7fhVUYt8cmM8G5=nhtpg@mail.gmail.com>

On Thu, Dec 24, 2020 at 12:17:26AM +0000, Mike McLean wrote:
> These seem fair concerns.
> 
> Detailed multi-line commits are something that I know exist, but I've
> never seen much need or use for, personally, and no project teams I've
> ever worked on have used them.
> But if that's the declared preferred-approach then I agree that this
> feature would be actively detrimental to that and thus is not
> appropriate.

The preferred approach is a single line summary of the commit,
followed by a body of text explaining the "why" of a commit.  In some
cases, the "why" may be several paragraphs explaining a one line
change.  For example, in this commit, see how much explanation was
given for a single _character_ change:

https://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git/commit/?h=dev&id=5a3b590d4b2db187faa6f06adc9a53d6199fb1f9

Having detailed messages is critically important; since even the
commit author is not likely to remember all of the details of a
particular change a even few months later --- and when examining
changes that was made by others, sometimes years latter, context can
be critical to understanding what was going on.

Certainly, if I were reviewing some public git repository belonging to
someone who was interviewing for a position at $WORK, and they had one
line commit descriptions, I personally would consider that to be a
signal that their software engineering skills might be lacking.
Having good commit descriptions is right up there with having good
regression tests and having a second engineer do code reviews (which
include reviewing the commit description for sufficiency) as part of
basic software development practice.

Cheers,

					- Ted

      reply	other threads:[~2020-12-24  4:25 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAM0jFOfx+vxvUAqZqnxeOvGmn0F0Q6vyTKWPjtsSh1bmq__SsQ@mail.gmail.com>
2020-12-23 23:07 ` Git Feature Request (Commit Message editing directly from interactive rebase control file) Mike McLean
2020-12-23 23:33   ` Junio C Hamano
2020-12-24  0:06   ` brian m. carlson
2020-12-24  0:17     ` Mike McLean
2020-12-24  4:21       ` Theodore Y. Ts'o [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=X+QXYhSnuIOdeeCv@mit.edu \
    --to=tytso@mit.edu \
    --cc=git@vger.kernel.org \
    --cc=sandals@crustytoothpaste.net \
    --cc=stixmclean@googlemail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.