Hacker News Reader

Comment by wirrbel | Hacker News Reader

I don't know how people are programming. I have good unit tests and regression tests and even though I commit frequently, most of the time I don't end up with single purpose commits and usually when I trace back commit history these single purpose commits don't help me much, even if the team mates were writing commit messages like these.

How much time do people spend to put too changes they did almost at once to make the code compile or the tests pass into two commits?

Much more valuable are larger commits at the size of a small PR.

View on HN

I don’t understand why the history of the code matters so much to some people. Give me well designed and commented (!) code, with tests, designed to be understood by humans. Thats a bar few code bases clear, if I need to look at the git history its a sign the code is crap and I have to use all the information that I can get, with history being my least favorite because it has shitty UX (discoverability, navigation).

Having properly separated and single-purpose commits is awesome when running `git bisect` [1] — especially with automatic tests. As well when you revert said commits after the offender is found.

[1]: https://git-scm.com/docs/git-bisect

If you're using a CI that runs on every PR/master merge wouldn't it catch this without the need for git-bisect?

Only if your tests have perfect coverage. And by "perfect" I don't mean lines or branches, but program states.

>commented (!) code,

Comments become stale and will often not be updated as the code changes.

This is what code reviews are for. Why would you exclude comments from that? It certainly doesn't happen in our team.

Comments often refer to stuff that's not directly in the "review window" i.e. the actual diff plus additional context you'll see in a typical code review setup.

So even if people are conscientious about reviewing comment changes (and absence thereof!), too this often gets missed.

> I don’t understand why the history of the code matters so much to some people.

Having the git blame output of the line I'm changing is very helpful when determining the potential consequences of changing that line. If the history doesn't matter, then why bother with commit messages at all. You could essentially script your editor to run "git commit -a --allow-empty --allow-empty-message" every time you write the files to disk.

Our workflow is: - branch - commit first version, open Github PR with a text describing the PR, which is usually longer than the git commit message and contains links to notion pages and other things detailing the design - reviewers look at the code, and there is some to and fro with smaller commits until the PR is fine - code gets merged

So the main action happens outside of git. Maybe for other workflows git commit messages are more important.

As time passes, practically no actively maintained codebase is going to clear your bar. It's going to pass through several different teams, with different policies and standards. Eventually, parts of it are going to be put on life support, which generally means an understaffed team that scrambles to patch up the most egregious bugs, often with dirty hacks, because they have no time and resources to do massive rewrites that are necessary to fix things properly. Maintaining such codebases requires a lot of "code archeology", and good history makes it much, much easier.

Not sure I get your point. People will cut corners and mess up the code, but somehow the history could be excempt from this?

Reply on news.ycombinator.com