[awolf]

> If the first line of a commit message is a title, it changes the way you write it. It becomes just some text to introduce some more text, without any stress on the information density.

I agree with the author that commit messages should optimize for information density. However the example they provide does a poor job of this:

> This is a smart synopsis, as information dense as possible.

"This is a" is the type of thing that should never appear in a commit message as it could apply to EVERY commit message. Synopsizing is the action, but doesn't indicate what is being synopsized; one of the most important facts for someone to understand what is happening here. Finally "as information dense as possible", again should also be cut as this is telling us HOW not WHAT (and ironically hurts information density).

Were I writing this example it would be:

  Synopsize how to write a commit message

---

I led an initiative at my current company to enforce all commit messages start with an imperative verb and be less than 72 characters. Some people hate it, some people love it.

Aside from standardization, the primary reason to do this is the imperative mood leads to the most concise sentence possible. By leading with the action, the most natural thing to do next is to talk about what is being acted upon. Unnecessary words are dropped and the most important facts are emphasized. In short it forces the author to get to the point.

  [Act] upon [some aspect of the code]

e.g.

  Add user login link on home screen
  Refactor authentication into separate classes
  Lint PR titles conform to standard format

[singlow]

I agree with your idea but I would take it further. If possible I think the commit message is more concise if it can actually refer to the resulting action that is the result of the change to the code, unless the primary result of the commit is to refactor or clean up code formatting, etc. This way we avoid one more level of indirection to indicate that we edited code to accomplish something, since that is always the case.

Link to login from home screen Enforce standard for PR titles

For refactoring, applying linting changes, or general formatting, I do prefer a prefix to indicate that it is not intended to change behavior. Something that is consistent for a project is good such as "Refactor:" or "Reformat:" or "Lint:" as a prefix to make it easy to spot these in the history is good.

I often see message such as:

Implemented new framework to... Edited 3 files...

Then someone will edit it to be imperative and it reads:

Implement new framework to... Edit 3 files...

Which is not really any better. They were past tense indicative because they described the actions of the programmer which are in the past. Writing from the imperative is not just better because it is more concise in english (shorter verbs) but because it is the natural way to describe what will happen in the program when the commit is merged.

[schrodinger]

> I led an initiative at my current company to enforce all commit messages start with an imperative verb and be less than 72 characters.

You are truly doing god’s work :). I’ve led a similar initiative and same outcome, some love, but those who don’t, really hate it.

[heavenlyblue]

Why do they hate it? Are those the creative ones that can’t conform?

[C14L]

Plus, I like to start with the topic the commit was about, so its easy to scan for a part of the codebase. E.g.

    user/login: Add link on home screen
    auth: Refactor into separate classes

[bagacrap]

I've literally never heard or read the word synopsize so I'd get stuck there wondering what the heck was happening. Try "summarize".

[awolf]

sure, was just matching what the author said in their example. 100% agree no need to use obscure words

[wwright]

I’m jealous that your environment is competent enough that commit messages are actually worth the time to fix.

[AlexCoventry]

> all commit messages start with an imperative verb and be less than 72 characters

Just the first line, right?

[awolf]

yes