Petr Baudis <pasky@xxxxxxx> writes: > 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? - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
