Hacker News Reader

Comment by naavis | Hacker News Reader

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

Reply on news.ycombinator.com