[PATCH] Automatically line wrap long commit messages.

[PATCH] Automatically line wrap long commit messages.

[Shawn Pearce]

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(-)

diff --git a/git-commit.sh b/git-commit.sh
index a092b72..e7aa4b1 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -547,7 +547,12 @@ fi
 
 if test "$log_message" != ''
 then
-	echo "$log_message"
+	# The message came from the command line.  It might contain very
+	# long lines so reformat it with a target of 60. Note that we
+	# don't reformat messages created in an editor by the user as
+	# we should assume they carefully formatted it in some way.
+	#
+	echo "$log_message" | fmt -w 60
 elif test "$logfile" != ""
 then
 	if test "$logfile" = -
-- 
1.3.3.g45d8

Re: [PATCH] Automatically line wrap long commit messages.

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 745 bytes --]

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

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

MfG, JBG

-- 
Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481             _ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  _ _ O
 für einen Freien Staat voll Freier Bürger"  | im Internet! |   im Irak!   O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] Automatically line wrap long commit messages.

[Shawn Pearce]

Jan-Benedict Glaw <jbglaw@lug-owl.de> wrote:
> On Mon, 2006-05-29 04:57:39 -0400, Shawn Pearce <spearce@spearce.org> wrote:
> > 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.
> 
> Uh? Just put it in quotes and press the Enter key when applicable.

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.

Re: [PATCH] Automatically line wrap long commit messages.

[Junio C Hamano]

Shawn Pearce <spearce@spearce.org> writes:

> 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.

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.

Re: [PATCH] Automatically line wrap long commit messages.

[Shawn Pearce]

Junio C Hamano <junkio@cox.net> wrote:
> Shawn Pearce <spearce@spearce.org> writes:
> 
> > 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.
> 
> 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:
[snip]

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

> 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.

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.

Re: [PATCH] Automatically line wrap long commit messages.

[Junio C Hamano]

Shawn Pearce <spearce@spearce.org> writes:

> OK.  Ignore both patches then.  Two negative votes in such a short
> time suggests they are probably not generally accepted.  ;-)
>
>> 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.
>
> 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.

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.

Re: [PATCH] Automatically line wrap long commit messages.

[Shawn Pearce]

Junio C Hamano <junkio@cox.net> wrote:
> Shawn Pearce <spearce@spearce.org> writes:
> 
> > OK.  Ignore both patches then.  Two negative votes in such a short
> > time suggests they are probably not generally accepted.  ;-)
> >
> >> 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.
> >
> > 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.
> 
> 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.

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.

Re: [PATCH] Automatically line wrap long commit messages.

[Junio C Hamano]

Shawn Pearce <spearce@spearce.org> writes:

> Junio C Hamano <junkio@cox.net> wrote:
>
>> 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.
>
> 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.

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.

Re: [PATCH] Automatically line wrap long commit messages.

[Shawn Pearce]

Junio C Hamano <junkio@cox.net> wrote:
> Shawn Pearce <spearce@spearce.org> writes:
> 
> > Junio C Hamano <junkio@cox.net> wrote:
> >
> >> 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.
> >
> > 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.
> 
> 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.

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.

> 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.

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.

Re: [PATCH] Automatically line wrap long commit messages.

[Junio C Hamano]

Shawn Pearce <spearce@spearce.org> writes:

> 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...

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).

> 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.

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