Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What a good commit message looks like (2011)

github.com

Post reply on HN
Print view View original

61–70 of 100 posts

Re: What a good commit message looks like (2011)

#61

Post by aninhumer »

masklinn wrote: post #56
aninhumer wrote: post #54

Earlier quoted context omitted.

>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?

> 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: * thi…

>Because wrapped code is generally nonsensical.

Not really? It's probably slightly more awkward to read than scrolling, but then, the solution is to read code on an appropriately sized screen in the first place.

And incidentally, truncated code definitely is nonsensical.

>List items.

They can be handled as you mention, but it's hardly the worst thing in the world if they're not.

And if you really care about formatting this much, you should use a format that encodes it properly (e.g. Markdown) instead of producing the text equivalent of a PDF.

Re: What a good commit message looks like (2011)

#62

Post by chris_7 »

masklinn wrote: post #45
chris_7 wrote: post #32

Earlier quoted context omitted.

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 fo…

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.

Is there not precedent for handling that

    correctly in a plain text field?

Re: What a good commit message looks like (2011)

#63

Post by greenhatman »

masklinn wrote: post #45
chris_7 wrote: post #32

Earlier quoted context omitted.

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 fo…

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.

I guess we want to use markdown in commit messages then.

Re: What a good commit message looks like (2011)

#64

Post by rogual »

hatmatrix wrote: post #60
chris_7 wrote: post #17

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 "git log" will show things nicely even when it's indented. Software should help me, I shouldn't have to help it. Why doesn't git handle this formatting automatically? I shouldn't need to manually break lines for typographical (not paragraph) reasons.

emacs magit tells me the commit message is too long when I exceed one line. Something seems wrong...

It's probably trying to tell you to leave a blank line between the title and the body of the message.

Re: What a good commit message looks like (2011)

#65

Post by chris_7 »

AckSyn wrote: post #55
chris_7 wrote: post #17

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 "git log" will show things nicely even when it's indented. Software should help me, I shouldn't have to help it. Why doesn't git handle this formatting automatically? I shouldn't need to manually break lines for typographical (not paragraph) reasons.

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…

Tools that handle formatting for you are a productivity multiplier and not having them but enforcing a specific style is wasteful.

Re: What a good commit message looks like (2011)

#66

Post by raimue »

Avshalom wrote: post #3

>74 characters path dependency is hell of a drug.

The reason for this is that Git patches are meant to be exchanged over email. Historically email has a line limitation of 80 characters. You are supposed to use less than that to allow insertion of quoting characters in the first columns in replies.

Re: What a good commit message looks like (2011)

#67

Post by falcolas »

chris_7 wrote: post #62
masklinn wrote: post #45

Earlier quoted context omitted.

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.

Is there not precedent for handling that correctly in a plain text field?

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).

Re: What a good commit message looks like (2011)

#68

Post by jbattle »

k__ wrote: post #31
jbattle wrote: post #28

Earlier quoted context omitted.

until the git killer comes along and the team decides how much history they are willing to migrate. I've seen it happen every 5(?) years across several companies. Ironically it's always the oldest commit messages that turn out to be the most valuable because newer changes people remember

What is "The Git Killer"?

yep as telo.. said - whatever will inevitably supercede git. In my own work it was VSS > Perforce > svn > git

All of those were good choices when they were new, and suboptimal choices when the next better solution came along.

Re: What a good commit message looks like (2011)

#69

Post by hasbroslasher »

AckSyn wrote: post #55
chris_7 wrote: post #17

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 "git log" will show things nicely even when it's indented. Software should help me, I shouldn't have to help it. Why doesn't git handle this formatting automatically? I shouldn't need to manually break lines for typographical (not paragraph) reasons.

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…

> 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?

This is a classic form of non sequitur. This kind of logic is the driver behind "If you can't be arsed to dress up in a suit and tie then you don't really care about your job" and "If you don't support our troops you are a Bad Person and you should leave the country".

Empirically, no one has shown formatting git commit messages to be predictive of code quality whatsoever. Sure, good engineers tend toward longer, more descriptive commits, but whether or not they follow proper text wrapping is totally beside the point. Poor code formatting is indicative of lack of skill, poor commit message formatting is indicative of a lack of knowledge of this one web page that most people have probably never seen.

Re: What a good commit message looks like (2011)

#70

Post by k__ »

jbattle wrote: post #68
k__ wrote: post #31

Earlier quoted context omitted.

What is "The Git Killer"?

yep as telo.. said - whatever will inevitably supercede git. In my own work it was VSS > Perforce > svn > git All of those were good choices when they were new, and suboptimal choices when the next better solution came along.

I had the feeling companies would just stick to their thing.

Last I worked with used CVS and always talked about switching to SVN, but never did.

Post reply on HN