Hacker News Reader

Comment by pmontra | Hacker News Reader

The most important tip is "Use the body to explain what and why vs. how".

I'd also say: remove thw -m option from git and force people to open the editor. Do not accept messages shorter than 3 lines, start the editor with a template

  Title

  What changed and why it changed.

View on HN

For my own commits in my personal repos I often find that less than 80 chars are sufficient to describe the change entirely. I generally don't care about surpassing 80 chars for commit messages though, so even if my commit message is somewhat long I won't split it up.

I commit very often and usually small, "atomic" changes most of the time.

What I will do, is that I start the commit message with the most important sentence and add less important sentences after, so even if it exceeds 80 chars and you can't see the whole message you will still get the most relevant info without having to scroll sideways.

For reference, here are the commits to a project I am currently working on: https://github.com/eriknstr/jumper/commits/master

Dogmatism like "commit messages must be at least three lines" will result in commit messages like:

  here's
  some
  code.

Concentrating on form over substance is myopic.

Totally agree. Using three lines of text to describe fixing a typo in the comments or rewording/reformatting a block of text will just lead to an unclear message.

It's likely that this would push the tools toward being too opinionated. I spend a lot of time pushing little WIPs so I know where I am and my macros rely heavily on -m, e.g. I end up with a commit message like "WIP: don't merge these debugging lines" or "WIP: Tweak the IO timeout and profile". -m is also useful for making trivial commits, I don't use it for this often because it's easy to violate 50 chars but it's a perfectly valid use of the tool IMO.

You can easily enforce this if you want through a pre-commit hook, but this is frankly ridiculous to enforce on everybody.

From SO:

>Git can take the commit message from a file using the -F or --file flags:

>git commit -F message.txt

So something like

    echo 'pmontra\n say\n this\n should be several lines' | git commit -F /dev/stdin

would get around your block.

You want printf, not echo.

echo is a very non-portable command. POSIX says: "if any of the operands contain a <backslash> character, the results are implementation‐defined."

why would the portability of the commands I type directly into my shell matter?

In your shell, it doesn't matter much.

In a HN comment, it matters, because other people will read the comment and may learn bad habits.

Reply on news.ycombinator.com