5 ms·

I’ve found the commit message guidelines at https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project https://git-scm.com/book/en/v2/Distributed-

by abtinf 7y ago

I’ve found the commit message guidelines at https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project https://git-scm.com/book/en/v2/Distributed-Git-Contributing-... to very helpful for clarity. “ The last thing to keep in mind is the commit message. Getting in the habit of creating quality commit messages makes using and collaborating with Git a lot easier. As a general rule, your messages should start with a single line that’s no more than about 50 characters and that describes the changeset concisely, followed by a blank line, followed by a more detailed explanation. The Git project requires that the more detailed explanation include your motivation for the change and contrast its implementation with previous behavior — this is a good guideline to follow. Write your commit message in the imperative: "Fix bug" and not "Fixed bug" or "Fixes bug."”

nirvdrum 7y ago
50 chars seems pretty arbitrary to me. I'd rather have a useful commit message. I've seen some pretty contorted messages conveying no real info in order to meet an imaginary character limit.
- hakre 7y ago
  the 50 chars is for the subject. the commit message (body) has no character limit (apart from a character limit per line).
  - hoseja 7y ago
    It's still overly restrictive and ossified from terminals / email subjects or whatever.
  - nirvdrum 7y ago
    Right. But that's the limit I don't get. If I always have to view the expanded set of commit messages to understand anything about the commit, what's the value in a short subject? And why 50 chars? That's even more restrictive than the normal 72/76/80 chars.
    - cyphar 7y ago
      It's so that when you print the git-log graph, you don't end up with wrapping of the subject text for deeply-nested trees. Also, in the kernel generally you reference a different commit in a commit message with the form 'commit <12 char commit id> ("subject")'. So further restricting it makes sense.
      - nirvdrum 7y ago
        Okay. But I contend that makes the whole log worth less because the short commit messages are often devoid of useful info. Granted, I don't have an email-based patch workflow; I look at logs on both GitHub and pulled in from the CLI. On GitHub, things are even worse because I have to constantly expand commits to see what actually changed. In any event, I think teams should be free to adopt the workflow that works best for them without tools getting in the way. GitHub wrapping commit messages at 70 chars, even though I have more than plenty enough horizontal real estate, isn't helping anyone.
    - GordonS 7y ago
      I think a limit is helpful to keep the subject line short, but I frequently (like, daily) struggle to fit useful messages into only 50 chars. Personally, I find 72 chars to be the sweet spot. I wish GitHub or Azure DevOps made this configurable (because I use them) - anyone know if any other hosted git systems have this as a configurable option?
      - nirvdrum 7y ago
        I'm in favor of a team being able to set a limit if they'd like and tools adapting. Personally, I'd rather a 90 char commit message that conveys useful info than a contorted message intended to fit in 1/3 the size of an SMS message.
deleted 7y ago
[deleted]

by abtinf 7y ago

nirvdrum 7y ago

50 chars seems pretty arbitrary to me. I'd rather have a useful commit message. I've seen some pretty contorted messages conveying no real info in order to meet an imaginary character limit.

hakre 7y ago
the 50 chars is for the subject. the commit message (body) has no character limit (apart from a character limit per line).
- hoseja 7y ago
  It's still overly restrictive and ossified from terminals / email subjects or whatever.
- nirvdrum 7y ago
  Right. But that's the limit I don't get. If I always have to view the expanded set of commit messages to understand anything about the commit, what's the value in a short subject? And why 50 chars? That's even more restrictive than the normal 72/76/80 chars.
  - cyphar 7y ago
    It's so that when you print the git-log graph, you don't end up with wrapping of the subject text for deeply-nested trees. Also, in the kernel generally you reference a different commit in a commit message with the form 'commit <12 char commit id> ("subject")'. So further restricting it makes sense.
    - nirvdrum 7y ago
      Okay. But I contend that makes the whole log worth less because the short commit messages are often devoid of useful info. Granted, I don't have an email-based patch workflow; I look at logs on both GitHub and pulled in from the CLI. On GitHub, things are even worse because I have to constantly expand commits to see what actually changed. In any event, I think teams should be free to adopt the workflow that works best for them without tools getting in the way. GitHub wrapping commit messages at 70 chars, even though I have more than plenty enough horizontal real estate, isn't helping anyone.
  - GordonS 7y ago
    I think a limit is helpful to keep the subject line short, but I frequently (like, daily) struggle to fit useful messages into only 50 chars. Personally, I find 72 chars to be the sweet spot. I wish GitHub or Azure DevOps made this configurable (because I use them) - anyone know if any other hosted git systems have this as a configurable option?
    - nirvdrum 7y ago
      I'm in favor of a team being able to set a limit if they'd like and tools adapting. Personally, I'd rather a 90 char commit message that conveys useful info than a contorted message intended to fit in 1/3 the size of an SMS message.

deleted 7y ago

[deleted]