• @[email protected]
    link
    fedilink
    41 year ago

    The reason for the approximately 50 character limit is because there’s many tools that display a single line and will truncate it if it’s more than about that length (though really the point of truncation can vary wildly – plenty of tools will let you go twice that before they cut you off). So if your one line summary is too long, it’ll be cut off and harder to understand your commit at a glance.

    You always can elaborate in a second paragraph, at any rate.

    • @[email protected]
      link
      fedilink
      11 year ago

      How much can you really put in 50 characters?

      Fix: NPE in customer download component when users – That’s 50 characters. Should I not mention where I fixed the bug?

      Fix: NPE when users downloaded customers without s – I think I can get rid of the actor in some cases.

      ̀ Fix: NPE when downloading customers without select`. The summary I want to give cannot be truncated any further.

      Fix: NPE when downloading customers. This fits, but is so vague as to be pointless as a summary, in my view.

      • @[email protected]
        link
        fedilink
        41 year ago

        I don’t follow the 50 character rule, but to answer your first question: imo, no, don’t mention where you fixed the bug. This is a commit message that is explicitly tied to the place where you fixed the bug. You can go into more detail in the PR if you need to.

        • @[email protected]
          link
          fedilink
          2
          edit-2
          1 year ago

          “PR” lol. I’m the sole developer.

          Jokes aside. I find it easier to have all the information in a commit message, so I can browse it in the git log without having to find the relevant PR(s) that finally merged it.

      • @[email protected]
        link
        fedilink
        3
        edit-2
        1 year ago

        Fixes #23132: NPE when downloading customers

        Reading that you see:

        • It’s a bugfix, not feature addition or such
        • The actual ticket number in case you need to dig deeper.
        • A quick blurb about what and where. The rest is in the code. If the issue title is good you often can simply re-use it (but not always).

        It’s plenty to orient yourself in case you need to dig in, plenty so that you can skip over the commit if you’re looking for something else, and short enough to ignore. If you absolutely need to document more, do it under the fold but that headline there is what should show up in a list of commits.