4 ms·

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

by Jsone 5y ago

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.

ComputerGuru 5y ago
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.
badsectoracula 5y ago
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.
elliotbnvl 5y ago
I haven't either, really. I suspect it's a matter of scale.
throwaway_egbs 5y ago
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.
skybrian 5y ago
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.
samhh 5y ago
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.
wyoung2 5y ago
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.
hnthrowaway8493 5y ago
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.
handrous 5y ago
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)

by Jsone 5y ago

ComputerGuru 5y ago

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.

badsectoracula 5y ago

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.

elliotbnvl 5y ago

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

throwaway_egbs 5y ago

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.

skybrian 5y ago

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.

samhh 5y ago

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.

wyoung2 5y ago

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.

hnthrowaway8493 5y ago

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.

handrous 5y ago

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)