Hacker News Reader

Comment by Jsone | Hacker News Reader

I have to admit, in my career so far, I've never had to, or seen anyone have to, interact with a commit more than a sprint or two old. Almost all my workplaces enforced the usual standards regarding linear history, squash/rebases before PRs and commit naming, and then did absolutely nothing with the results of that effort. It probably means that I've had an atypical career, but I still wonder if all these ceremonies are as meaningful as we hold them to be.

View on HN

For most projects, history gets used less and less the older it is. That's also true of the code. A lot gets abandoned or scarcely used.

But for the most important, widely used, long-lived projects, things are different. You come to appreciate history when you have legacy code that you want to change and you'd like to figure out what the authors were thinking when they wrote it. (Unfortunately, too often, the version control history wasn't kept at all.)

I think that we often assume our code is more important than it is, so we use ceremonies that aren't appropriate. But this is hard to judge in advance. The people writing long-lived code often didn't know that they were writing it.

How else do you answer questions like "How long has this been broken?" And without the answer to that, how do you know who needs to upgrade, and who doesn't?

I'm sure you can install old binaries to answer this sometimes, but I'd prefer to do it with a DVCS bisect, since that'll narrow the matter down to the individual commit that broke things.

Working in open source, I’ve interacted with commits that predate git and were imported into it a decade ago, whether to track a bug, see how changes correlated, or check the historical behavior of a function. I couldn’t work without the ability to do so.

I've successfully looked at commits years old to understand the context around a feature/bug that was confusing myself and a product owner. This context is where small, well-detailed commits come in so handy beyond just the initial review.

Same here, and I’ve worked at everything from mom-and-pops to a couple of household names. IME this (seemingly endless) discussion about how to manage commit history is the tabs-versus-spaces of source control.

Interesting - I've only worked on pretty small eng teams, but I couldn't live without git blame (or an editor/IDE feature using git blame). It's like another dimension, seeing the history of code line-by-line and learning why it was added, especially if those lines are months or years old. With clean linear commit history and clear commit messages you can easily see not just what was changed, but why it was changed, along with other commentary from the author and often a test plan.

FWIW i often had to go backwards in history (that was with Perforce, not Git) in previous jobs to figure out when a bug was introduced and by who so i can see what was the logic behind the change (either from the commit message or by asking the person directly, if they were still around). It can be helpful to avoid breaking something else by mistake when trying to fix something that had a reason to be as it is.

It's basically only done when something goes wrong, IME. All but the most recent history exists mainly for git-bisect and being able to branch historical versions to patch some old release-in-the-wild (if you're developing on the Web with a modern release-often style, the latter may rarely happen for, as you write, "a commit more than a sprint or two old", but it's common on software with longer release cycles or long-supported older versions)

I haven't either, really. I suspect it's a matter of scale.

Reply on news.ycombinator.com