Re: [PATCH] git-commit: Reformat log messages provided on commandline

From: Junio C Hamano <junkio@cox.net>
Date: May 10, 2007, 00:45 UTC
Message-ID: <7vsla5pkug.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20070509142426.GV4489@pasky.or.cz>

Petr Baudis <pasky@suse.cz> writes:

Show 11 quoted lines

> diff --git a/git-commit.sh b/git-commit.sh
> index f28fc24..28cbb55 100755
> --- a/git-commit.sh
> +++ b/git-commit.sh
> @@ -432,7 +432,7 @@ fi
>  
>  if test "$log_message" != ''
>  then
> -	echo "$log_message"
> +	echo "$log_message" | fmt
>  elif test "$logfile" != ""

Two points.

 * You would not want to wrap the first line;

 * 75-column is not ideal for every project, so this needs to be
   customizable;

 * If we were to munge the given message, we would probably also
   want to enforce "single-liner summary, empty line, and then
   the rest" convention.

Well, I have three there, but I suspect the first two somebody else may have said already, so...

This is slightly related, but I have been wondering about the interaction with "single-liner summary, empty line and then the rest" convention and various commands in the log family.

Currently, --pretty=oneline and --pretty=email (hence format-patch) take and use only the first line. I think we could change it to:

 - take the first paragraph, where the definition of the first
   paragraph is "skip all blank lines from the beginning, and
   then grab everything up to the next empty line".

 - replace all line breaks with a whitespace.

This change would not affect well-behaved commit messages that adhere to the convention, as their first paragraph always consist of a single line. On the other hand, people from different culture can get frustrated by their commit message chomped at the first linebreak in the middle of sentence right now, which would be helped by this change.

Their Subject: and --pretty=oneline output would become very long and unsightly, but their commit messages are already ugly anyway, and such a change at least avoid the loss of information.

If we were to do this, Subject: line would most likely use RFC2822 line folding at the places where line breaks were in the original, but that goes without saying.

What do people think?