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

71–80 of 100 posts

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

#71

Post by masklinn »

chris_7 wrote: post #59
masklinn wrote: post #46

Earlier quoted context omitted.

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

Markdown renderers seem perfectly capable of this. git wouldn't even need to disambiguate asterisk for lists vs. asterisk for emphasis.

So every piece of software now needs a markdown renderer?

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

#72

Post by jtmarmon »

collyw wrote: post #47

One problem with this is that git gets used as a deployment tool as well as a version control system. Trying to get something to run on Heroku involved making lots of small changes just to get things to run on the server the same as on my dev machine. When you do that 10 or 20 times the commit message become somewhat meaningless.

generally when I'm trying this stuff I'll make a new branch to work off of and deploy from that. when I've figured out how it needs to work, I'll squash the commits and merge into master.

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

#73

Post by compsciphd »

gumby wrote: post #39
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.

m-X auto-fill-mode. You can add this to other modes automatically. I almost always have it on. Added to Emacs in 1977.

auto-fill mode doesn't reflow paragraphs at will, it just inserts a line break when you go over the limit.

For instance, if you're editing a document and write a long sentence, that spreads over 3-4 lines. You then take a scalpel to it to make it more concise, so that it fits on a line or 2. Emacs won't reflow it automatically, you can manually get it to reflow (M-q by default), but its not the behaviors you expect from say a word processing program. Same exists if you insert new text.

TLDR: all auto-fill mode does is insert new lines when you reach the line length limit.

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

#74

Post by marcosdumay »

raimue wrote: post #66
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.

Your email client is supposed to fix this restriction in a completely transparent way. There are a few standards for that, and you can bet every client supports all of them.

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

#75

Post by __strisk »

don't use git commit messages as "dear diary" sort of things.

For example:

"I fixed the button issue on the homepage. Still, need to center the title."

would be better written as:

"fixes button issue on homepage"

Always think about what that commit does to the codebase. This is obviously for single-line commits. I suppose it would be okay to "dear diary" in the commit body. You can provide rationality or context in the commit body.

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

#76

Post by raimue »

marcosdumay wrote: post #74
raimue wrote: post #66

Earlier quoted context omitted.

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.

Your email client is supposed to fix this restriction in a completely transparent way. There are a few standards for that, and you can bet every client supports all of them.

Uhm, no, that is not the reality we live in. Things like format=flowed exist, but I would not say that "all" clients support that. For example Apple Mail lately got an obsession for quoted printable encoding with very long lines.

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

#77

Post by greenhatman »

gregmac wrote: post #38
svckr wrote: post #26

Here's what, Tim Pope, our favourite vim nerd has to say about this: http://tbaggery.com/2008/04/19/a-note-about-git-commit-messa... (Same, but with more words.) A point of contention seems to be the choice of the imperative, at least for the subject line. While I'm really used to it, both when reading and writing, many people seem to strongly prefer past tense ("Fixed bug …" instead of "Fix bug …").

More importantly, the correct way is the way that is currently being used . If the project uses past tense, use it. If you want to change the convention, that's okay too, but everyone has to change. It's exactly the same issue as coding style. If you can look at code or commit messages and figure out who wrote it based purely on style/formatting, you're doing it wrong (or rather: the person using the inconsistent sty…

Tenses in commit messages seem a bit pedantic and inconsequential. It doesn't really affect much. Unlike tabs vs. spaces, where mixing would cause a mess.

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

#78

Post by masklinn »

aninhumer wrote: post #61
masklinn wrote: post #56

Earlier quoted context omitted.

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

> Not really?

Yes really.

> but then, the solution is to read code on an appropriately sized screen in the first place.

That's not a solution to anything.

> And incidentally, truncated code definitely is nonsensical.

Truncated code is visibly truncated, not nonsensical garbage right next to actual code.

> They can be handled as you mention

And the software knows what a list item is… how?

> it's hardly the worst thing in the world if they're not.

One more fantastic non-solution to listed problems, we're definitely going places.

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

So you're saying git should embed a markdown renderer and text layout engine?

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

#79

Post by masklinn »

greenhatman wrote: post #63
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.

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

That provides absolutely no help. Markdown-formatted messages doesn't give you a plain-text renderer and text layout engine.

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

#80

Post by makecheck »

aninhumer wrote: post #44
gumby wrote: post #39

Earlier quoted context omitted.

m-X auto-fill-mode. You can add this to other modes automatically. I almost always have it on. Added to Emacs in 1977.

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.

Except that almost every time, I am composing and viewing the log messages from a terminal. The logical thing for a web page to do is to display logs as “preformatted” text (because they are, same as code).

It would be interesting to have a way to indicate a formatting style when composing a log message though; for instance, a way to indicate that a log contains Markdown code.

Post reply on HN