Hacker News Reader

Comment by interactivecode | Hacker News Reader

That’s horrible because the git commit messages are easily lost, disconnected or hard to find in any reasonably active codebase. For example as soon as you do a change and move a file it almost always disconnects from the previous change history.

Whats even more difficult is searching through a code base when the documentation isn’t in or near the code. I don’t know any IDE or editor that makes it easy to search though git commit message and source code at the same time.

On top of that, do you review git commit message in code review? Do you aks people to improve descriptions, typos and language in commit messages?

View on HN

I don't understand how they are hard to find. It's trivial to find where the file was moved from.

What I truly care about is why something is the way it is, what is the rationale behind it, how it works with other parts of the codebase, what problems it solves, what is tricky about it, what to pay attention to and so on. I don't care at all about the code that was written and an explanation to it because this I can read myself in the code. The best place I've found for this is a code commit because it can tie different parts of the codebase together and add a lot of context to a change. I commit heavily and don't squash. A long comment in a commit that contains all file changes related to a certain feature, bug or whatever adds a lot more information than a comment in one file. When other people do it, it helps me a lot more than chasing their (outdated) code comments throughout the codebase.

But if that doesn't work for you, then don't do it. Just don't be dogmatic and dismissive. I accept there might be situations and codebases where this doesn't work.

I'm lost. Are you talking about meta-level comments, like "here's why this change is being made", that aren't directly tied to any particular line of code? If so, certainly putting that stuff in commits makes sense.

But for regular "explanatory note about this variable/function/etc" comments, how does one work if those things are in commit logs? If you're reading code and something is unclear, do you look back through the commit messages of every commit that's ever touched that line, just in case one of them has something relevant?

IDEs can show commit history. But you're right that it can get messy tracing back to the original commit when a file has been changed many times.

But for the most part I feel like comments should be automated tests. If a line is there for an edge case it should have a matching test for that edge case.

The only exceptions I see are for performance optimizations or some other situation where you can't easily test.

> IDEs can show commit history.

How you check the commit history is beside the point - the question is, do you read the entire commit log history for a chunk of code before editing it?

If not, any comments there might as well not exist - functionally speaking you're maintaining an uncommented codebase.

Tests are not a replacement for comments or documentation. Tests check that A() returns x but don't explain what is A, x and why it should return it.

That goes in the test name. You'll have something like

Feature A

"It should return X in [some edge case]"

That's where any link to a use case should be.

Lot's of IDEs and external tools do very basic git integration ¯\_(ツ)_/¯

I think JetBrains is probably the best of the IDEs

Your comments applies very little to commit messages, and much more so to comments.

> That’s horrible because the git commit messages are easily lost, disconnected or hard to find in any reasonably active codebase. For example as soon as you do a change and move a file it almost always disconnects from the previous change history.

Learn your tools or get better ones, `git log --follow` has no issues with renames, and when files get munged in ways it can't handle (e.g. content is split out or merged) it's easy enough to stitch back, and good annotate UIs (Jetbrain's is stellar and one of the few things I don't use magit for) make flitting through a snippet's history trivial.

Meanwhile finding removed comments is nearly impossible (VCS are nowhere near as good for finding when was removed than when it was added), and comments can easily drift apart from their point of origin as developers aren't too careful about maintaining them when adding unrelated comments.

> On top of that, do you review git commit message in code review? Do you aks people to improve descriptions, typos and language in commit messages?

Bet your ass I do.

> I don’t know any IDE or editor that makes it easy to search though git commit message and source code at the same time.

Any editor from Jetbrains with the GitToolbox plugin does that.

Can second that. Having the commit message as a virtual comment on the end of the current line is immensely helpful in tracking changes. It’s like git blame on steroids.

I also like seeing the commit messages in this way! In the case of VSCode this comes with the Git Lens extension.

  git log --follow -p file

edit: here's another

  git log -p -L:show_commit:builtin/rev-list.c

> On top of that, do you review git commit message in code review? Do you aks people to improve descriptions, typos and language in commit messages?

Absolutely I do. The commit message is part of the commit just like the code; why would it be excluded from review? The number of times that a good commit message has helped me when dealing with a bug, and that a poor one has stymied me, have firmly convinced me that they are just as important as any other project documentation. They should be clear and informative, and I ask for those aspects to be improved when needed.

Reply on news.ycombinator.com