depends. for small commits, a one-liner suffices. For large commits, merge commits, etc., or for repos that require you to sign-off on the commit or whatnot, a one-liner followed by a blank line and then a nice paragraph or bullet-point list is necessary. "launching a full editor" is hardly a problem with emacsclient or vi[m]

Writing descriptive commit messages with multiple lines.

If I'm not using some integrated VCS system (which currently happens quite often), it's still mostly the case that I just switched from an editor when I'm writing my CLI commit command. So the mental context switch to transfer back into an editor setting is pretty minimal. And with the editor running (or EDITOR being vi(m)/emacsclient), the startup is negligible, too. So since the time of CVS, and now with either SVN or git, I just don't care too make a difference between small or larger commit messages and completely ignore options of expressing my commit message on the shell, going to the editor all the time.

I found that this also encourages me to be a bit more specific about the reasons for the changes committed. A few lines don't really hurt.

On the other hand, it might be that my commit schedule might still be too influenced by the older VCS systems, and a more frequent git-ish approach would encourage a more in-line approach. But right now I think that my one or two additional lines help more than they hurt.

Please do not do this. Please.

Build up your commit with git add -p (which requires an editor), then git commit -v and check what you are committing again.

Even if you do you'll still need EDITOR for interactive rebase.