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

91–100 of 100 posts

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

#91

Post by masklinn »

aninhumer wrote: post #90
masklinn wrote: post #78

Earlier quoted context omitted.

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

>That's not a solution to anything. I'm not sure what scenario you're imagining where you absolutely have to read code in commit messages on an unreasonably narrow screen, and you can't wait until you have an appropriate machine. But if a scenario occurred where that were important, I'm sure you'd manage to read some wrapped code, it's not that hard. >Truncated code is visibly truncated Unless it's not, because there…

> If you really want pristinely formatted commit messages that badly then yes.

Mate, I already have pristinely formatted commit messages, because I format them as I desire.

You are the person telling me I shouldn't be formatting my messages and a nebulous "software" ought do that, the burden's on you to give them the tools which yield the same pristinely formatted output I already achieve without a formatted input.

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

#92

Post by aninhumer »

masklinn wrote: post #91
aninhumer wrote: post #90

Earlier quoted context omitted.

>That's not a solution to anything. I'm not sure what scenario you're imagining where you absolutely have to read code in commit messages on an unreasonably narrow screen, and you can't wait until you have an appropriate machine. But if a scenario occurred where that were important, I'm sure you'd manage to read some wrapped code, it's not that hard. >Truncated code is visibly truncated Unless it's not, because there…

> If you really want pristinely formatted commit messages that badly then yes. Mate, I already have pristinely formatted commit messages, because I format them as I desire. You are the person telling me I shouldn't be formatting my messages and a nebulous "software" ought do that, the burden's on you to give them the tools which yield the same pristinely formatted output I already achieve without a formatted input.

You have pristinely formatted commit messages when viewed in ~80 column monospace, but poorly formatted commit messages anywhere else.

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

#93

Post by forgottenpass »

omginternets wrote: post #57
AckSyn wrote: post #55

Earlier quoted context omitted.

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.

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

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

#94

Post by wolfgang42 »

__strisk wrote: post #75

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

My recommended style is:

    Fix button issue on homepage
    
    This allows the title to be centered,
    as the button will no longer collide with it.
Then, in a subsequent commit, center the title and put a reference to this one if you feel it's important, like so:

    Center the title on the homepage
    
    It wasn't previously because it would collide with the button,
    but that was fixed in f00b1f.

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

#95

Post by Avshalom »

masklinn wrote: post #71
chris_7 wrote: post #59

Earlier quoted context omitted.

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?

we don't even need markdown. Groff and less are already there and already handle formatting and reflowing just fine.

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

#96

Post by masklinn »

Avshalom wrote: post #95
masklinn wrote: post #71

Earlier quoted context omitted.

So every piece of software now needs a markdown renderer?

we don't even need markdown. Groff and less are already there and already handle formatting and reflowing just fine.

Groff is a text processing/formatting system so same issue, and less doesn't handle jack shit.

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

#97

Post by wruza »

chris_7 wrote: post #83
masklinn wrote: post #71

Earlier quoted context omitted.

So every piece of software now needs a markdown renderer?

If Linus wants a consistent commit message format, he should enforce it at the software level, rather than hoping people read a comment he left in a repository about logging his swimming information. This does not mean that the format needs to be Markdown (which includes embedded HTML, so obviously not Markdown), or that all software needs a Markdown renderer. I'm not sure why you'd conclude that.

Enforcing is an administrative task committed by specific people in specific projects (there is a thing called 'best practice', but it never is a hard rule). Tools authors should not enforce anything, it's not their job, responsibility and competence, even if a particular project like Linux has the same Linus for both project management / rcs tool writing.

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

#98

Post by AckSyn »

chris_7 wrote: post #65
AckSyn wrote: post #55

Earlier quoted context omitted.

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.

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

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

#99

Post by wruza »

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.

On the other hand, non-terminal people should not use terminal-oriented software along with flowing text ideology. We do not even distinguish line breaks / paragraph breaks for now (though we often emulate that via \n\n). We do not have add-indent-level and cut-indent-level character codes for to not mess with indent. Markdown may seem good, but it is still low-level format, like rtf or html; it isn't natural in any way. We just pretend that good old-and-new Unix tools are perfectly applicable to modern textual fashion, when they really aren't.

That said, it is arguable if we must do that step forward from the development perspective. These tools already solved real issues, and now we discuss preferences. Personally, I'm fine with terminal on the left and wrap-capable editor on the right. It's not "to support software", I really like it more.

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

#100

Post by chris_7 »

AckSyn wrote: post #98
chris_7 wrote: post #65

Earlier quoted context omitted.

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

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

Why did you only quote part of that sentence?
Post reply on HN