Hacker News Reader

Comment by rco8786 | Hacker News Reader

I think I would prefer this style.

And also the discourse around commit messages and their various flavors may be one of the biggest wastes of time in terms of ROI in our industry.

I’ve been doing this for 14-15 years and can probably count on two hands the number of times I’ve needed to look at historical commit messages.

View on HN

What's tremendously useful for us to have in the commit message, is the ticket ID the work is related to in our issue management system, to the point where it is practically mandatory.

I see it as a matter of scoping communications. The issue management system includes a broader set of people than the git repo. You want the commit linked to the issue so that you can see the entire history behind the commit, including the business decisions, the designer making a call, the back and forth with QA etc. That can all be useful a year or two down the road if you want to understand why something was done a certain way.

Now there is some info about the change that perhaps only the devs would ever care about, and probably that can sit in the commit messages. That sort of happens naturally but there's not really a lot of it for us. But that seems to me to be the relevant thing from an organizational perspective, no one writes commit messages except for devs, and almost nobody except the devs reads them.

This is what I came here to say. Assuming the team is working from JIRA or something, put the ticket number in the commit message. The ticket itself is where your “why” goes.

It's really nice to have the actual reasoning in the commit history though. But maybe I was just scarred by the project that switched project management software like 5 times over its lifetime (but kept all of the commits) though.

I’ve been through this in a job. The commit messages were borderline worthless, ostensibly the context was in a JIRA ticket that hadn’t existed in a decade, and I couldn’t figure out if a change was a mistake or something clever and poorly documented. It’s frustrating, a huge waste of time, and runs the risk of introducing subtle defects into the code today.

I can't stand the ticket number in the message. It's an immediate waste of 6-10 characters on meaningless metadata that GitHub can pull from the body and link for you. Further, the numbers are sequential, so frequently VERY similar, and highly prone to typos, which is harmful to anyone even minorly dyslexic.

> that GitHub can pull from the body

I think that breaks the thing that people want which is being able to `git commit -m "Fix #234353"` without a body at all.

Use multiple messages.

`git commit -m "Fix actual words that humans read" -m "Fixes: #234353"`

You could probably script this based on branch if you're one of those people who names branches after ticket numbers.

But my actual advice is that I think -m is a bad pattern that leads to bad commit messages, and omitting the message argument opens your EDITOR, and you should use that.

I wonder if Atlassian encourages and sells this as an ideal use case [for JIRA]. What a great way to make it really painful to leave their system if in order to make sense of your repo history you to need to maintain the references to their system. They are making your repo dependent on their ticket system...

I look at past commits probably every week or two to track down why something is the way it currently is.

Having said that, I care very little about style and grammar of commit messages. Ideally I want them to say why the change was made, what the intended effect was, and where I can look for related work (bugs that tracked the work and have related commits or investigation attached to them, docs, whatever)

Hit rate on the information I'd like is not great, but if I get at least one of the three things then it's something I can work with.

I'd say I look at commits ~weekly, especially when trying to understand 'WTF did he do that?' - context of tracing the commits (and offtimes back to individual PR when commit is poorly formatted) is valuable.

Blame & diffs are much more useful to me in the context of GitHub. I don't care about someone's subjective ~50 char description of a change. The important part is the pull request itself and that it references whatever issue prompted the change.

Commit messages have only ever been useful in tracking my own intermediate work products. Often times, I will leave helpful bread crumbs in my commit notes if I know I won't be working on something for a few days. We strictly do squash+merge, so I don't have to worry about these things causing trouble for others. All of our commits into master have some standardized "Issue #1234" note as automatically copied from the PR title (which we do have ~standardized).

If we didnt have some git wrapper like GitHub available, then I suspect we'd be significantly more aggressive with policy around our commit messages.

If your process requires trashing the commit messages it's not surprising you don't find them useful.

I don't know, I do it almost daily. So your mileage may vary.

I do it almost daily too. What _is_ rare, is finding a commit message that tells me anything useful that I couldn't have derived from the diff also. I don't need your life story, but sometimes some context about why something was needed is great.

Exactly. Im in git history all the time. But the messages themselves…eh. Im basically always looking for a change in a specific file or set of files, and then I just pull up the diffs.

What I do find useful is the subject/area, and the author.

Author here. Yes, the diff should tell you more, but you shouldn't need to look at the diff until you have an idea what the contents of that diff are about. It's like the links on the hacker news home page -- clicking them will always tell you more, but the index should be geared for the use case, which is scanning, typically.

I'm not sure that suits everyone's most common use case. (I'm not arguing that it may well suit yours.) I guess on paper it makes sense that commit messages are the top-level entry point to changes. But since we're packaging up a lot of our work in merge requests, the commit messages already get snowed under. Folks arrive in a merge request, and often can't care less about the commit messages that make up the merge request, they may read the message on the merge request, familiarize themselves (ideally) with the story in (ugh) Jira, and then jump to the diff for the review they came there to do. It's the later version of you that is browsing through the code base and wants to understand how a certain current piece of code came about, who then clicks on the gutter in, let's say, IntelliJ, and clicks through to the commit, where both the diff and the commit message are shown.

Indeed, and since we don’t do pull requests (we pair, mob, and/or do live code reviews), the after-the-fact git blame or the git log to see what has changed recently is what tends to matter.

I agree that when I did PRs I didn’t tend to care about the commit messages when I was reviewing them, but even when I did do PRs I cared about them later any time I was trying to understand how, why, or who forensically.

It is so odd to me as I don't remember a single instance during my 10 years of experience having done that. Only if I was asked by someone else in the org why something is the way it is have I gone to history to see what the ticket number is for the referred change to get an explanation and this is more related to the product.

I wonder what is so different about our workflows, that some people do it all the time and others almost never.

Are we working on somehow very different things.

To me I find that code is the source of truth and current state, it doesn't really matter to me as much why or how something came to be as I look more into how I can make the current thing work with what I am to do.

Maybe you don't debug bugs? Work on recent and clean codebases?

Or simply the projects you work with have poor commit messages?

I do, and I also work on legacy systems. It just never occurs to me that commit history would somehow help me instead of just looking at the current state of the code.

I would say however that the commit messages mostly are just squashed pull requests with ticket names and single sentence so I'd agree that they wouldn't be very good for that purpose, but I don't see anyone at the org complaining about this.

It's mostly on the Internet I read how others use the git history, but I haven't seen anyone really doing a lot of that in real life.

For me it's usually blame, look for a line that hasn't been touched by some triviality, then from that commit message either to a ticket reference, or, if absent or unavailable, to history shortly before and after. So yes, I do look at old history. In a codebase that has seen a lot of squash rewriting that won't be of much help of course.

> I would say however that the commit messages mostly are just squashed pull requests with ticket names and single sentence so I'd agree that they wouldn't be very good for that purpose, but I don't see anyone at the org complaining about this.

There’s your answer.

Yep

I personally look more often at past commits, but I've still never really had a need to scan a list of changes like this. I really don't see the point of the advantage they're claiming, even if it's real.

What I normally do is, while investigating a tricky bug and finding some lines that don't make sense, look through history to see why those lines were introduced (to see if they fix something else), and perhaps when (to see which versions may be affected by a hard-to-reproduce bug). But that typically pinpoint a commit already, and I just need the commit message to explain why it was there.

It does sort of feel a bit cargo culty sometimes. I expect commit messages are situationally important, as a function of the size and maturity of the project, the size of the development team (esp. the amount of developer churn).

That said, there's probably some fringe benefit to describing what you do in some fashion. It's a great way of making sure you understand what's happening yourself.

I find much more cargo cult in disregarding commit messages

How does that work? Like a cargo cult behavior is a ritual you do because you think it will bring about some good through unknown means. Disregarding commit messages is the absence of a ritual.

Disregarding is an action too (and I don't think you need a ritual in cargo cult behaviors)

The difference is that if disregarding commit messages has no effect, then it's still beneficial to do since you're saving effort vs writing elaborate commit messages.

In my experience in the long term, on average, you'll lose insanely much more time.

Deducing lost information (or trying to deduce it) often takes enormously much more effort than what it takes to write it down.

Maybe version control is a cargo cult, then? You might as well just make commits without commit messages if the revision comment is useless. Maybe just squash all commits between versions so you just have one commit per version.

This is a demonstrably faulty conclusion. Even without commit messages, version control lets you do things that you would not be able to do otherwise, such as to roll back a failed refactoring attempt, for example.

That is very possible to do. People overwrite their save data or their files without any VCS getting in the way.

It’s not like you need the history (is this a refactor or something else? doesn’t matter) so you don’t need to keep around such failed attempts.

It's still a substantial improvement to have known snapshots of the state of the code. It doesn't have to be in VCS, like you can roll it old school and save full zips of the code base, but snapshots are a tangible benefit that VCS offers that does not hinge in the slightest upon well written commit messages.

<10 instances of looking at the commit history in >10 years is exceptionally little. I think you may have a different use-case if your commits are write-only and crafting commit message texts is probably a waste of time at that rate

Which is a very interesting take, for what it's worth. Might be worth a blog post what circumstances lead to this working well for your organization!

Reply on news.ycombinator.com