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
