Junio C Hamano <junkio@xxxxxxx> wrote: > Shawn Pearce <spearce@xxxxxxxxxxx> 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. - : 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