6 ms·

The body of the commit message can be several paragraphs, and please do proper word-wrap and keep columns shorter than about 74 characters or so. That way "gi

• raimue 10y ago
  That software is called a text editor and you can configure it to do the text wrapping for you. More seriously, it is quite hard to wrap text correctly after you submitted it. For example people add manual line breaks for structuring text and to separate things like quoted commands from the rest. It would be much more cumbersome to go back after a git commit to fix this, probably in multiple iterations until you get the intended presentation instead of just doing it right from the start.
  • chris_7 10y ago
    Web browsers line break text dynamically just fine - as do, well, text editors. Using a text editor to automatically embed line breaks doesn't fix the problem: embedding line breaks in text for formatting is wrong semantically. Hard line breaks should mean something. Now I can't reflow the text to display it on a web page in a normal font, because I can't be sure of which line breaks are meaningful, and which are formatting.
    • masklinn 10y ago
      Except now you need everything to handle textual contexts because while I do want my nice paragraph of text to be wrapped, I don't want my code snippet to be wrapped at all, and I want my nested list to be correctly intended at wrapping.
      • chris_7 10y ago
        Is there not precedent for handling that correctly in a plain text field?
        • falcolas 10y ago
          Which, in the case of HN and other pages, can either break the formatting of the entire page by pushing the right margin beyond the window, or artificially constrained windows which you need to scroll sideways on. Text layout is a hard problem. It's why TEX (and its derivatives) is still so damned useful (and complicated).
          • chris_7 10y ago
            It's really not that hard in this case. Don't wrap lines with a four-space prefix (or whatever format is decided), wrap lines without one. Allow users to disable the wrapping if they prefer wrapped code. The prefix can be stripped at display time if you wish, so that code is left-aligned - actually, since the formatting isn't encoded in the log, only the semantics, users can configure the display as they please. Possible handle lines beginning with - as lists and indent them correctly. If a message somehow breaks the format, do not accept it. This isn't TeX-level complexity.
      • greenhatman 10y ago
        I guess we want to use markdown in commit messages then.
        • masklinn 10y ago
          That provides absolutely no help. Markdown-formatted messages doesn't give you a plain-text renderer and text layout engine.
    • deleted 10y ago
      [deleted]
  • deleted 10y ago
    [deleted]
  • BurningFrog 10y ago
    OPs point remains. It's git's job to tell me its limitations. Not my job to adapt my tools to it. When practical, of course. In this case, git could simply give a "are you sure you want to commit with these long lines?" warning.
    • petepete 10y ago
      Git copes just fine with long commit messages. Providing the rest of your team is happy with it and your tools can display it ok, just do it.
      • usea 10y ago
        Agreed. My last two jobs had no line length limit on commit messages (or code) and it was great. But culturally, C# developers don't live in an 80-column terminal window, either.
• gumby 10y ago
  m-X auto-fill-mode. You can add this to other modes automatically. I almost always have it on. Added to Emacs in 1977.
  • aninhumer 10y ago
    The point is that people shouldn't be littering their text with hard line breaks just to support software that can't do word-wrapping properly. That your editor can do this doesn't mean you should. It might make the text look a bit prettier in an 80 column terminal, but it makes it worse pretty much anywhere else.
    • masklinn 10y ago
      > The point is that people shouldn't be littering their text with hard line breaks just to support software that can't do word-wrapping properly. How can the software guess whether a given line should be wrapped (text), should not be wrapped (code), should be wrap-indented (list item) or should be wrap-prefixed (quote block) when it's only given raw bytes assumed to be text without further information?
      • aninhumer 10y ago
        >should not be wrapped (code) I'm not sure why this matters much? If the code doesn't fit on the screen you're viewing it on, then it's not going to be convenient to read regardless of whether you wrap it or have a horizontal scroll. >should be wrap-indented When would you have an indented line that shouldn't be wrap-indented?
        • masklinn 10y ago
          > I'm not sure why this matters much? Because wrapped code is generally nonsensical. > If the code doesn't fit on the screen you're viewing it on, then it's not going to be convenient to read Inconvenient is one thing, nonsensical is an other. > When would you have an indented line that shouldn't be wrap-indented? That's noted right after, in the parens: list items. This is not correct wrapping for a list item: * this is a list item this is correct wrapping for a list item: * this is a list item If the display software does not do that (and I'm reasonably certain most would not) I'd much rather properly hard-wrap my text before committing it, that way I know that it will end up correctly wrapped and actually readable.
• AckSyn 10y ago
  Translation: I won't want to do the extra work to format my commit messages. How I understand that: If you can't format your commit messages, how can you be considered reliable to format your code how the company defines it? I'm sure someone can write a patch for git commit comments to enforce a 74 character limit on line width with CR\LF indiscriminately or separate them "smarter" by breaking words at 0020 after it crosses the 74 character width limit. But that's besides the point.
  • omginternets 10y ago
    >Translation: I won't want to do the extra work to format my commit messages. Patient: "It hurts when I move my arm". Doctor: Don't move your arm. It's absurd to take a principled stand against software alleviating development pain.
    • forgottenpass 10y ago
      It's absurd to take a principled stand against software alleviating development pain. lolwut? Is anyone saying: "don't write a commit-msg hook!" or "how dare you configure a programmer's editor to wrap at a fixed width?" I see a lot of what boils down to: "it's not my problem how you and your teams go about following a formatting standard that's popular but not mandatory."
  • chris_7 10y ago
    Tools that handle formatting for you are a productivity multiplier and not having them but enforcing a specific style is wasteful.
    • AckSyn 10y ago
      > but enforcing a specific style is wasteful Tell that to the plentiful amount of businesses and software development groups that enforcing good coding style is wasteful. I'll wait.
      • chris_7 10y ago
• hatmatrix 10y ago
  emacs magit tells me the commit message is too long when I exceed one line. Something seems wrong...
  • rogual 10y ago
    It's probably trying to tell you to leave a blank line between the title and the body of the message.