Junio C Hamano <junkio@cox.net> wrote:
quoted text
> 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.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html