Re: Git Feature Request (Commit Message editing directly from interactive rebase control file)

From: Theodore Y. Ts'o <tytso@mit.edu>
Date: Dec 24, 2020, 04:21 UTC
Message-ID: <X+QXYhSnuIOdeeCv@mit.edu>
In-Reply-To: <CAM0jFOfA2HH9gC0RRX52NSEPGcsCg_7fhVUYt8cmM8G5=nhtpg@mail.gmail.com>

On Thu, Dec 24, 2020 at 12:17:26AM +0000, Mike McLean wrote:

Show 8 quoted lines

> 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