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

How to write a Git commit message (2014)

cbea.ms

Post reply on HN
Print view View original

161–170 of 185 posts

Re: How to write a Git commit message (2014)

#161

Post by zoomablemind »

In my experience, when possible, the commit messages should read as part of a spec, describing the implemented behavior (mostly imperative). Even when fixing a bug, the commit would state what the code is intended to do, just as its resp. test exercises.

This way it's somewhat easier to follow the reasoning of the committed changes.

Another detail is to prefix a subsystem affected, that's in case of modular or complex application. Also help focus the attention.

My preference in general is to write single line messages (shorter ok, longer - ok too), unless it's something very non-trivial and source-code policy discourages lengthy comments.

Re: How to write a Git commit message (2014)

#162

Post by incomingpain »

gbear605 wrote: post #153
incomingpain wrote: post #151

I have only been using git for a few years. subversion was popular for a long time. I rarely pay much attention to git commit messages. I would very much rather look at the diffs and see where/what it changed. >Capitalize the subject line Does this really matter? Really?

It matters to the same degree as being consistent about variable naming. It doesn’t change whether the system works, but if everyone is consistent then it’s easier to read and understand later.

> It matters to the same degree as being consistent about variable naming. It doesn’t change whether the system works, but if everyone is consistent then it’s easier to read and understand later.

I must admit I don't like that PEP rule. Camel case in some places, no capitals in other places. I just whatever I want really.

Re: How to write a Git commit message (2014)

#163

Post by kgeist »

atq2119 wrote: post #156
kgeist wrote: post #115

We also have a rule to prepend every commit message with its issue number in our issue tracker (we don't use GitHub). That way in Git Blame/Log you can always quickly find where the change came from and why - the issue tracker usually has more detailed information.

Curious, I've run into this approach in the past and learned to hate it with passion. That place used JIRA where the typical ticket ID was around 10 characters. That wasted a lot of prime real estate, e.g. in my email inbox, in history views (tig, gitk, and so on). I also don't see the claimed benefit for git blame. In a real code base with significant history, it happens often enough that the first blame is an unrel…

I view the commit message first, of course, and only if it's not enough, I go to the issue tracker.

>That place used JIRA where the typical ticket ID was around 10 characters. That wasted a lot of prime real estate

Interesting, just for the sake of it, I measured how much screen space the issue ID takes up on my monitor with my current font settings - around 5% (of monitor width, of course). Never been a problem for me.

Re: How to write a Git commit message (2014)

#164

Post by coldacid »

twhitmore wrote: post #114

Interesting topic. From my experience Headline + Bullet Points are far quicker to convey useful information, in a form that is terse yet easy to read. For example: ---------------- improve Buffer Cache Management & logging - change 'tryDrop()' to skip immediately, if lock unavailable - move BufferCache logging to a separate logger - attach BufferTrim.Unsuccessful -> Preemptive Flush of oldest buffers ----------------…

Bullet points are fine, but again the message should contain the context of the change and the "why" of it, not the what and how (that's what the diff shows).

Re: How to write a Git commit message (2014)

#165

Post by xorcist »

elpakal wrote: post #56
1ark wrote: post #51

Earlier quoted context omitted.

Not sure why downvoted, this is the "correct" way. Can also do --autosquash etc. at the same time.

what makes this more correct than the other way? if anything an interactive rebase requires a lot more ceremony

Throwing away the commit and doing it again can easily go wrong. It is easy to commit unintended changes by mistake.

The interactive rebase is a completely normal operation and intended for exactly this situation. It is also much easier to craft more than one commit, and last minute fixes of spelling errors and such things.

Re: How to write a Git commit message (2014)

#166

Post by revskill »

tremon wrote: post #157
revskill wrote: post #137

Mine is "[JIRA_TICKET] Add something" It's simple and worked well for us so far. Less rules, more information, and developers are free to use their words to express intention of changes instead of nonsense (feat, fix,....)

Have you gone through a ticketing system change yet with a developer team? I've seen several, and not once was "we must import the old PR's/issues/features into the new system" given any serious consideration. Conversely, every source control system migration I've seen took great pains to preserve the committer, the date and the full commit message of each separate commit. Point being, in a few years all your [extern…

OK, my question is, no effective commit message system exists without a consistent ticket system.

A ticket reference gives you all you need. You see it in every line of code, from there you know the reason for that code to be written, it could include a reference to slack discussion url,...

Re: How to write a Git commit message (2014)

#167

Post by everybodyknows »

kazinator wrote: post #140

I will play the devil's advocate: why would anyone outside of the realm of die-hard FOSS on Unix-like systems wrap text to 72 columns? Look, I'm not doing it now. This entire paragraph I'm entering into HN is one giant line of text that gets wrapped. Suppose you're working on software for which patches will not be sent to FOSS mailing lists that are anti-HTML, anti-MIME, anti-long-line, ... why would you wrap the bod…

> Why would anyone outside of the realm of die-hard FOSS on Unix-like systems wrap text to 72 columns?

Because if the commit is performance related, including regression test results may be mandatory. Test results will be in some fixed format e.g. tabular, commonly exceed 72 columns, and become gibberish if wrapped.

Re: How to write a Git commit message (2014)

#168

Post by kazinator »

everybodyknows wrote: post #167
kazinator wrote: post #140

I will play the devil's advocate: why would anyone outside of the realm of die-hard FOSS on Unix-like systems wrap text to 72 columns? Look, I'm not doing it now. This entire paragraph I'm entering into HN is one giant line of text that gets wrapped. Suppose you're working on software for which patches will not be sent to FOSS mailing lists that are anti-HTML, anti-MIME, anti-long-line, ... why would you wrap the bod…

> Why would anyone outside of the realm of die-hard FOSS on Unix-like systems wrap text to 72 columns? Because if the commit is performance related, including regression test results may be mandatory. Test results will be in some fixed format e.g. tabular, commonly exceed 72 columns, and become gibberish if wrapped.

If it becomes gibberish when wrapped, why would you do exactly that?

If I have 200 column wide regression test results in a nice tabular format, maybe that's the way it should stay in the commit message.

Re: How to write a Git commit message (2014)

#169

Post by stinos »

u801e wrote: post #160
stinos wrote: post #127

Earlier quoted context omitted.

I don't really have a problem with bullet points, conveying relevant information is after all the most important thing the message should do, but if that example is an actual one then it would raise some flags during review. Mainly because it's not super readable (mix of styles, super terse requires extra interpreting) but also because it mostly explains what has changed (most often unneeded information, as that shou…

> it mostly explains what has changed (most often unneeded information, as that should be clear from the diff) and not really why it is done that way Ideally, commit messages should at least briefly explain what was changed (e.g., Add feature X, Fix bug Y) in addition to why it was done. When people look at git log output, they won't always show the associated diff for each log message. Also, when running git blame,…

Ideally, commit messages should at least briefly explain what was changed

Yes, sorry didn't mention it explicitly, but that's normally what the first line of the commit message is for.

Re: How to write a Git commit message (2014)

#170

Post by atq2119 »

kgeist wrote: post #163
atq2119 wrote: post #156

Earlier quoted context omitted.

Curious, I've run into this approach in the past and learned to hate it with passion. That place used JIRA where the typical ticket ID was around 10 characters. That wasted a lot of prime real estate, e.g. in my email inbox, in history views (tig, gitk, and so on). I also don't see the claimed benefit for git blame. In a real code base with significant history, it happens often enough that the first blame is an unrel…

I view the commit message first, of course, and only if it's not enough, I go to the issue tracker. >That place used JIRA where the typical ticket ID was around 10 characters. That wasted a lot of prime real estate Interesting, just for the sake of it, I measured how much screen space the issue ID takes up on my monitor with my current font settings - around 5% (of monitor width, of course). Never been a problem for…

If you view the commit message first, then I don't see how having the issue ID as the first thing helps your git blame use case. You can see the issue ID just as easily in a footer line of the commit message.

As for screen space, one of the standard email client layouts has a vertical split, with message titles on the left and bodies on the right. This generally fits well with 16:9 screens, but the line width for titles is limited. Having e.g. the affected component or subsystem up front is much more useful when skimming.

Post reply on HN