patchAutomatically line wrap long commit messages.

When using -m on the command line with git-commit it is not uncommon for a long commit message to be entered without line terminators. This creates commit objects whose messages are not readable in 'git log' as the line runs off the screen.

So instead reformat log messages if they are supplied on the command line.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
 This one might cause some problems for people.  It requires
 'fmt' in order to use log messages on the command line as well as
 some users may not like having their log messages line wrapped.
 I'm open to suggestions for how to deal with this but personally
 this is one feature which I put into pg's commit tool that I miss
 dearly when working with core GIT.

 git-commit.sh |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)

On Mon, 2006-05-29 04:57:39 -0400, Shawn Pearce <spearce@spearce.org> wrote:

Uh? Just put it in quotes and press the Enter key when applicable.

MfG, JBG

Jan-Benedict Glaw <jbglaw@lug-owl.de> wrote:

I realize that. But I feel that it looks rather ugly on the command line, in the resulting message, and is difficult to do well all of the time.

For one thing the first line is offset due to the stuff preeceding it on the command line, even if you put the -m" on the next line. For another it goes nicely with my prior patch of allowing multiple -m flags on the command line and merging them into a single commit message by treating each option argument as its own paragraph.

Maybe its just me but I've generally found `fmt` does a nice job of line wrapping my text. I'm writing this email out in vi with no thought to line wrapping and will let `fmt` clean it all up for me before I sent it. I do the same thing with all of my commit messages; except git-commit won't let me do it from the command line.

This patch was trying to do that... but I suspected some folks would not like the idea very much. :-)

Shawn Pearce <spearce@spearce.org> writes:

I am already moderately negative on multiple -m so in the light of it this one looks totally unneeded. You could do a number of things:

	$ git commit -m 'This is my message.

	This is the first line of the message body.'
        $ cat >L <<EOF
        This is my message.

	This is the first line of the message body.'
	EOF
	$ git commit -F L
	$ fmt <<EOF
        This is my message.

	This is the first line of the message body.'
	EOF
	$ git commit -F L

We probably should allow "commit -F -" to read from the standard input if we already don't, but that is about as far as I am willing to go at this moment.

Junio C Hamano <junkio@cox.net> wrote:

[snip]

OK. Ignore both patches then. Two negative votes in such a short time suggests they are probably not generally accepted. ;-)

We do.  So apparently the solution to my usage issue is:

	$ fmt -w 60 | git commit -F-
	This is my message.

	This is the body.  Etc....
	EOF

I'm thinking that's too much work for me. Which means either I learn to format my messages better in a single -m switch (as was already suggested) or I just deal with git-commit popping open $EDITOR anytime I want to commit something. In which case then I might as well also get a diff of what I am about to commit as part of the temp file buffer.

Or I create my own little wrapper shell script which calls fmt. Hmm, maybe that would be useful with alias and a promise to not use ci as a core GIT command name:

	[alias "ci"]
		command=shawns-commit-wrapper

Shawn Pearce <spearce@spearce.org> writes:

If we supported multiple -m (presumably each becomes a single line?) with internal fmt, I do not see how it would become less work.

	$ git commit -w60 -m "This is my message." \
        	-m '' \
        	-m 'This is the body.  Etc....'

looks more typing to me, even without the second line to force the empty line between the summary and the body.

Junio C Hamano <junkio@cox.net> wrote:

Actually I was thinking each -m would be its own paragraph so blank lines would split each -m and maybe the -w60 should be a config option in .git/config or .gitrc so it doesn't always need to be supplied on the command line.

Personally I want blank lines between each -m and to always run the message through fmt. Others may want to run their commit messages through other filters so maybe the filter itself is just a config value which gets executed:

	[user]
		commitMessageFilter = fmt -w 60

or someone else might set:

	[user]
		commitMessageFilter = /home/user/bin/my-filter

where the filter accepts the message on STDIN and writes (the maybe changed) message on STDOUT.

Shawn Pearce <spearce@spearce.org> writes:

Now that makes the distinction between the current:

	$ git commit -m 'This is my message.

	This is the body.  Etc....'

vs. the proposed multi-em:

	$ git commit -m 'This is my message.' \
        -m 'This is the body.  Etc....'

Presumably Etc.... will be an multiline argument to -m. The distinction is even more blurry to me than before.

Emacs users would just do "ESC q" and vi users would know how to filter the file contents through fmt, so this seems to come from aversion against invoking your $EDITOR. I just do not see why.

Having said that, I do realize that the current behaviour of accepting multiple -m without complaining and discarding all but the last one silently is far worse than what is being proposed, and I do not see downside to the multiple -m patch, so let's apply that. You can have your "fmt -w60" provided if it is made into an option.

Junio C Hamano <junkio@cox.net> wrote:

Because git-commit currently performs a status update and throws that data into the editor buffer. That takes longer than committing from the command line. Especially if I've just done a git-diff or git-status to see what is changed and about to be committed...

On a project the size of GIT on a Unix system this isn't a big deal; on a 9000 file project on Cygwin this difference is significant to me.

It is just the way I am used to working.

I'll rework the fmt -w60 patch to instead accept an optional filter command from .git/config; if the filter command is set then the command line commit message will get run through the filter before being piped into git-commit-tree.

Shawn Pearce <spearce@spearce.org> writes:

Ah, why does it take this many exchanges to extract the true motive behind what people do even in a technical forum like this, I wonder...

So what you want is not multiple -m options nor piping to fmt. What you really want is an option that is the opposite of -v to git-commit that omits the status list ("_could_ commit if you update-index" part -- since "will commit" is something we would need to compute anyway).

I suspect you are suffering from lstat() performance. I wonder if "assume unchanged" git help your situation?