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
prev parent 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$(echo .)edu \
--cc=git@vger$(echo .)kernel.org \
--cc=sandals@crustytoothpaste$(echo .)net \
--cc=stixmclean@googlemail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox