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

131–140 of 185 posts

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

#131

Post by stinos »

rafaele wrote: post #93

What do people think of this line? > Use the imperative mood in the subject line The only rationales I've seen for using imperative ("fix bug") over the indicative ("fixed bug") are that it's what git does by default anyways. Is it really that big of a deal to use the indicative sometimes and imperative other times? For what it's worth, I always write commit messages in the imperative, out of habit. When others write…

I use imperative, but for other projects which don't I switch to indicative if that is the style. Personally like imperative more, not sure why, just preference.

> Is it really that big of a deal to use the indicative sometimes and imperative other times?

'big', don't know, but wouldn't be surprised if there's an objectively provable higher cognitive load for having to read a mix of both (or, god forbid, other styles thrown in there as well) vs one consistent style. Just like there is for code etc. And some people are affected by striving for consistency more than others, so for them lack of consisteny might cause some extra friction.

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

#132

Post by eikenberry »

mdoms wrote: post #44
eikenberry wrote: post #6

Earlier quoted context omitted.

But the PRs aren't part of your git repository? IMO a git repository should be self contained and not require a hosted provide to give context. It lets you manage your work with superior local tooling and without a browser running. Basically I take the exact opposite approach where my PRs are always just a short summary of the commit messages and provides a place for me to put the github specific things like the "Fix…

I do 99% of my coding at work. At work we have Gitlab, Confluence and Jira and these all already contains mountains of context for all of our work. Pretending this context doesn't exist and storing it all in a Git repository isn't helpful.

I'm speaking of coding in a larger context then... Where it can exist outside of the limits of a single company and a single team. In those sort of cases no, it doesn't really matter where you keep the history. It is a business decision and it is up to the business to decide to switch providers and absorb the loss.

I'm speaking of code that others will read. Maybe it is free software, maybe it is proprietary but shared by a larger team, maybe you are writing for customers... any way about it, if the code is to be maintained and read again over time the development history should be captured by a revision management tool like git.

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

#133

Post by sudo_chmod777 »

onion2k wrote: post #130

Every time I read something about "how to write good commit messages" it always seems to focus on reading the messages back as a log. That's great if that's how you use commit messages, but I tend to use them more for searching for a specific change so it doesn't really work for me. A more narrative style in commits I might need to go back to makes it easier to find them later. How you write your commit messages shou…

Define 'specific change'.

A change driven by a business decision? Don't see how it won't work.

A change specific to a component? Try conventional commits with scopes.

Code change? You shouldn't use commit messages. Use e.g. `-G`, `-S`, `-L`, etc. instead.

By the way if you are not using fzf already, you should.

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

#134

Post by Gwypaas »

lamontcg wrote: post #90

I'm a heretic who prefers information in the PR. That's where the long-form back and forth arguments happen over the edge conditions. Periodically a few days after a PR has been merged I'll have a discussion with someone and realize some context was never captured, so I'll just add it at the bottom of the closed+merged PR for posterity. Yeah that means all the important information is in GH but if you migrate to GitL…

I subscribe to this and:

> "The Not Rocket Science Rule Of Software Engineering: automatically maintain a repository of code that always passes all the tests"

https://graydon2.dreamwidth.org/1597.html

Intermediate commits to produce a pretty history while not passing the tests reduce their usefulness to about zero.

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

#135

Post by hansoolo »

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.

Yup, we do the same and it works out pretty well this way.

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

#136

Post by toastal »

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.

This really treads on the char limit in the titles though

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

#138

Post by selcuka »

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.

We do the same and it works pretty well. The problem with that approach, though, the codebase may live for decades but issue trackers change and old tickets usually don't get migrated to the new system.

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

#139

Post by Traster »

Honestly, the best guidance is just "put more than 2 seconds effort into your commits". No one really believes "More code" is a good commit message, it's just laziness. So yeah, put a little effort in, it's literally one of the few parts of your work that will remain once you are gone. Most code I've worked on gets replaced/updated/modified after I'm done working on it - but the one thing that I know will stay is the git history that some poor bastard will have to search through to figure out why this random bit of code ended up this way.

The only other thing I'll say is don't be weird. I knew a guy who would prepend his commits with a [tag] saying what part of the repo his commit was touching. This was a mixed sw/hw project and every single commit of his started with [sw]. It's like, ok thanks, firstly, you're a software engineer working the ../sw/ folder, secondly no one was confused that your 17 changes to a C++ file were going to be a hardware change.

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

#140

Post by kazinator »

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 body of commit messages to 72 columns?

Post reply on HN