All of lore.kernel.org
 help / color / mirror / Atom feed
From: Shawn Pearce <spearce@spearce.org>
To: Junio C Hamano <junkio@cox.net>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] Automatically line wrap long commit messages.
Date: Tue, 30 May 2006 22:18:08 -0400	[thread overview]
Message-ID: <20060531021808.GC21222@spearce.org> (raw)
In-Reply-To: <7vhd373o15.fsf@assigned-by-dhcp.cox.net>

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.

  reply	other threads:[~2006-05-31  2:18 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-29  8:57 [PATCH] Automatically line wrap long commit messages Shawn Pearce
2006-05-29  9:00 ` Jan-Benedict Glaw
2006-05-29  9:14   ` Shawn Pearce
2006-05-29  9:16 ` Junio C Hamano
2006-05-29  9:46   ` Shawn Pearce
2006-05-30  8:38     ` Junio C Hamano
2006-05-31  2:18       ` Shawn Pearce [this message]
2006-05-31  5:05         ` Junio C Hamano
2006-06-01  3:34           ` Shawn Pearce
2006-06-01  6:37             ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060531021808.GC21222@spearce.org \
    --to=spearce@spearce.org \
    --cc=git@vger.kernel.org \
    --cc=junkio@cox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.