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

[Shawn Pearce <spearce@spearce.org>]

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.