Wrap commit messages on `git commit -m`

Hi,

Some of my colleagues are lazy to fire up an editor and write proper
commit messages- they often write one-liners using `git commit -m`.
However, that line turns out to be longer than 72 characters, and the
resulting `git log` output is ugly.  So, I was wondering if it would
be a good idea to wrap these one-liners to 72 characters
automatically.

Thanks.

Ram

Hi,

On 1 November 2012 16:07, Ramkumar Ramachandra [off-list ref] wrote:

Hi,

Some of my colleagues are lazy to fire up an editor and write proper
commit messages- they often write one-liners using `git commit -m`.
However, that line turns out to be longer than 72 characters, and the
resulting `git log` output is ugly.  So, I was wondering if it would
be a good idea to wrap these one-liners to 72 characters
automatically.

Can't you do this already?  From "git-log(1)":

 %w([<w>[,<i1>[,<i2>]]]): switch line wrapping, like the -w
option of git-shortlog(1).

-- Thomas Adam

On Thu, Nov 1, 2012 at 2:12 PM, Thomas Adam [off-list ref] wrote:

Hi,

On 1 November 2012 16:07, Ramkumar Ramachandra [off-list ref] wrote:

quoted

Hi,

Some of my colleagues are lazy to fire up an editor and write proper
commit messages- they often write one-liners using `git commit -m`.
However, that line turns out to be longer than 72 characters, and the
resulting `git log` output is ugly.  So, I was wondering if it would
be a good idea to wrap these one-liners to 72 characters
automatically.

Can't you do this already?  From "git-log(1)":

I think he's talking about git-commit wrapping the message as it is
being committed, instead of git-log doing the wrapping as it is being
displayed.

I personally would rather see git-commit refuse to accept messages
wider than 72 characters.

Ramkumar Ramachandra [off-list ref] writes:

| Hi,

| Some of my colleagues are lazy to fire up an editor and write proper
| commit messages- they often write one-liners using `git commit -m`.
| However, that line turns out to be longer than 72 characters, and the
| resulting `git log` output is ugly.  So, I was wondering if it would
| be a good idea to wrap these one-liners to 72 characters
| automatically.

git commit -m 'foo: fix this problem

This problem is fixed by doing foo,
bar and baz.

Signed-off-by: me
'

works.

-- 
	Lgb

As I see it, the problem is not the possibility to add new lines, but
colleagues being too lazy to add them.

On Thu, Nov 1, 2012 at 5:29 PM, Lars Gullik Bjønnes [off-list ref] wrote:

Ramkumar Ramachandra [off-list ref] writes:

| Hi,

quoted

| Some of my colleagues are lazy to fire up an editor and write proper
| commit messages- they often write one-liners using `git commit -m`.
| However, that line turns out to be longer than 72 characters, and the
| resulting `git log` output is ugly.  So, I was wondering if it would
| be a good idea to wrap these one-liners to 72 characters
| automatically.

git commit -m 'foo: fix this problem

This problem is fixed by doing foo,
bar and baz.

Signed-off-by: me
'

works.

--
        Lgb

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

Kevin wrote:

As I see it, the problem is not the possibility to add new lines, but
colleagues being too lazy to add them.

I suspect the underlying problem is that we make it too hard to tell
git which text editor to run.

Ram, what platform do your colleagues use?

Thanks,
Jonathan

Jonathan Nieder wrote:

Kevin wrote:

quoted

As I see it, the problem is not the possibility to add new lines, but
colleagues being too lazy to add them.

I suspect the underlying problem is that we make it too hard to tell
git which text editor to run.

Don't we just use $EDITOR?

Ram, what platform do your colleagues use?

Red Hat Enterprise Linux 5.

Ram

Ramkumar Ramachandra wrote:

Jonathan Nieder wrote:

quoted

Ram, what platform do your colleagues use?

Red Hat Enterprise Linux 5.

Oh, ok.  In that case I blame habit.

I think the best option you have is to just complain to your
colleagues about the long lines.  Then they would get a chance to
explore what the UI currently offers and to complain to this list
(perhaps via you :)) about missing features that would make their work
easier.

To put it another way: I don't see yet how a hypothetical "git commit
--wrap-lines -m 'long message'" would make life easier than just
running "git commit" and entering the message using $EDITOR.  There's
probably a UI or documentation bug lurking somewhere, so thanks for
thinking about these things.

Regards,
Jonathan

On Fri, Nov 2, 2012 at 11:38 PM, Jonathan Nieder [off-list ref] wrote:

Ramkumar Ramachandra wrote:

quoted

Jonathan Nieder wrote:

quoted

quoted

Ram, what platform do your colleagues use?

Red Hat Enterprise Linux 5.

Oh, ok.  In that case I blame habit.

I think the best option you have is to just complain to your
colleagues about the long lines.  Then they would get a chance to
explore what the UI currently offers and to complain to this list
(perhaps via you :)) about missing features that would make their work
easier.

To put it another way: I don't see yet how a hypothetical "git commit
--wrap-lines -m 'long message'" would make life easier than just
running "git commit" and entering the message using $EDITOR.  There's
probably a UI or documentation bug lurking somewhere, so thanks for
thinking about these things.

Regards,
Jonathan

If your colleagues do not mind using a GUI then git-cola
might help them form better commit messages.

It auto-wraps long lines and enforces a very clear distinction
between the one-line summary and extended description.
-- 
David

On Sat, Nov 3, 2012 at 3:41 AM, David Aguilar [off-list ref] wrote:

On Fri, Nov 2, 2012 at 11:38 PM, Jonathan Nieder [off-list ref] wrote:

quoted

Ramkumar Ramachandra wrote:

quoted

Jonathan Nieder wrote:

quoted

quoted

Ram, what platform do your colleagues use?

Red Hat Enterprise Linux 5.

Oh, ok.  In that case I blame habit.

I think the best option you have is to just complain to your
colleagues about the long lines.  Then they would get a chance to
explore what the UI currently offers and to complain to this list
(perhaps via you :)) about missing features that would make their work
easier.

To put it another way: I don't see yet how a hypothetical "git commit
--wrap-lines -m 'long message'" would make life easier than just
running "git commit" and entering the message using $EDITOR.  There's
probably a UI or documentation bug lurking somewhere, so thanks for
thinking about these things.

Regards,
Jonathan

If your colleagues do not mind using a GUI then git-cola
might help them form better commit messages.

It auto-wraps long lines and enforces a very clear distinction
between the one-line summary and extended description.

vim also does this nicely with syntax highlighting turned on, though I
do not know how this feature is triggered.

Specifically, it wraps all lines at 72 characters; it colors line 1
yellow out to 50 characters and white after that; and it colors any
text on line 2 with a red background (should be empty).

Phil

On Thu, Nov 1, 2012 at 11:29 AM, Lars Gullik Bjønnes [off-list ref] wrote:

Ramkumar Ramachandra [off-list ref] writes:

| Hi,

quoted

| Some of my colleagues are lazy to fire up an editor and write proper
| commit messages- they often write one-liners using `git commit -m`.
| However, that line turns out to be longer than 72 characters, and the
| resulting `git log` output is ugly.  So, I was wondering if it would
| be a good idea to wrap these one-liners to 72 characters
| automatically.

git commit -m 'foo: fix this problem

This problem is fixed by doing foo,
bar and baz.

Signed-off-by: me
'

works.

Perhaps a deeper issue is that the implicit email format
(subject-body) for commit messages, is, well, implicit. New users of
git who type git-commit -m '...' isn't going to know that those few
characters will all be lumped on a "subject" line, forever screwing
themselves when they review the output of git-log, git-rebase
--interactive, etc. (can't remember off the top of my head if
git-format-patch would chop off long subjects and move it to the
body), which may be a significant period of time (and thus commits)
later.

While I don't have any ideas on how to improve on this, hopefully this
gets recognized as an issue in the first place.

-- 
Cheers,
Ray Chuan