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

51–60 of 100 posts

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

#51

Post by vinhboy »

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.

I also commit like 20 things to get Heroku working properly. But after I am done with that, I `rebase` it into one commit. Then I push it into my `origin/master`, and force push `heroku/master`.

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

#53

Post by binarnosp »

I open an issue for every feature, bug or enhancement, then I mention the issue in the commit followed by a short description of the changes. I wrote down a procedure that I follow for every commit [1].

This allows me to keep the commit line short and to see the commits history related to the resolution of a bug or feature.

When using Gitlab, Bitbucket or Github the issues and the commits are cross-linked (example: [0]).

[0] https://bitbucket.org/binarno/imebra/issues/162/ [1] https://imebra.com/wp-content/uploads/documentation/html/sop...

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

#54

Post by aninhumer »

masklinn wrote: post #46
aninhumer wrote: post #44

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

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

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

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

#55

Post by AckSyn »

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 crosses the 74 character width limit. But that's besides the point.

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

#56

Post by masklinn »

aninhumer wrote: post #54
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?

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

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

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

#57

Post by omginternets »

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…

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

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

#59

Post by chris_7 »

masklinn wrote: post #46
aninhumer wrote: post #44

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

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

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

#60

Post by hatmatrix »

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...
Post reply on HN