3 ms·

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

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.

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.