I get the feeling almost everybody uses an editor (vim, notepad++, etc) for the git commit messages. Why?
I find typing -m and a couple of quotes is easy and provides a easy way to redo a commit (pressing up arrow). I guess it's easier to do multi-line commit messages in an editor, but I have a hard enough time convincing fellow co-workers to write ANY message!
In an editor you can write longer messages, do formatting like justify to 80 columns, etc. Maybe you have a template for commit messages that you copy and paste. You can do these things in text editors.
I first began learning vim by setting it as my default editor for Mercurial; it forced me to at least know the basic commands if I wanted to get anything done. Now I use vim all the time.
You mentioned the most important thing - length. Commit messages should essentially always be multi-line. The only exceptions are trivial commits (e.g. "bumped version number to X.X.X") or merges with no conflicts (though even then, appending a shortlog isn't a bad idea). The average commit, as far as such a thing exists, should probably have a sentence or two beyond the subject; some could even have paragraphs. Just look at the log of git.git; it's pretty much guaranteed to be a good example of commit message style and length.
I realize that it may be hard to convince others to write good commit messages, but that doesn't mean you can't - and you will probably find it easier to use an editor to write them.
(I have exactly the same experience in my workplace. My coworkers are engineers first, programmers second, and version control users... third would be generous. But you can at least do your job right!)
Some people have conventions, such as the following:
Short (50 chars or less) summary of changes
More detailed explanatory text, if necessary. Wrap it to about 72 characters or so. In some contexts, the first line is treated as the subject of an email and the rest of the text as the body. The blank line separating the summary from the body is critical (unless you omit the body entirely); tools like rebase can get confused if you run the two together.
Write your commit message in the present tense: "Fix bug" and not "Fixed bug." This convention matches up with commit messages generated by commands like git merge and git revert.
Further paragraphs come after blank lines.
- Bullet points are okay, too
- Typically a hyphen or asterisk is used for the bullet, preceded by a
single space, with blank lines in between, but conventions vary here- Use a hanging indent
Good luck doing that without using an editor.
A proper git commit message should almost always be multi-line. From the official git-commit discussion,
Though not required, it's a good idea to begin the commit message with a single short (less than 50 character) line summarizing the change, followed by a blank line and then a more thorough description. Tools that turn commits into email, for example, use the first line on the Subject: line and the rest of the commit in the body.
If you're having a hard time getting any commit messages, (talk to your sysadmin and/or) make sure that at least one of the GIT_EDITOR environment variable, the core.editor configuration variable, the VISUAL environment variable, or the EDITOR environment variable is set to something useful.
An option would be to create your own 'editor', which prompts for a short (<50 chars) description, and then a minimum number of characters or sentences. This might not be well received, but that would depend on your position and the culture of your work environment.