4 ms·

I find it a lot easier to read a commit log when it's consistent in style.

• anton_gogolev 11y ago
  Regardless of whether commit messages are in past or present tense, have trailing period or not, properly capitalized or not -- they are all equally unreadable with all the "Merge pull request #20552 from jamesdabbs/belongs-to-polymorphic-force-reload" junk.
  • harperlee 11y ago
    Yeah, that's something that I never understood. The most important information is not that this is a merge, but the intent of the branch. You can give extra detail in the extended part, but the title should not be just referencing the way in which those changes found their way to the branch, and not what they do as in the rest of commits...
    • gknoy 11y ago
      I believe Github lets one add extended commit messages for merge commits. Most of us (including me) tend to ignore that and use the autogenerated one. It'd be nice if we had an easy option to automatically include the PR's description (first comment) as the merge commit's message.
  • djur 11y ago
    `git log --no-merges` saved me a lot of headaches after switching to a pull request-based review model at work.