3 ms·

This is the response I expected to see here. Reading through the article, I'm reminded of my dismay reading this exact sentiment every time version control is

This is the response I expected to see here. Reading through the article, I'm reminded of my dismay reading this exact sentiment every time version control is discussed. So many people are so quick to throw away their history so that things look "tidy". It makes no sense, but somehow it fits a certain programmer-brain logic that is surprisingly common. My style is to commit often. Like dozens of times per day. Commits are the record of what happened, and I want as much of that record to exist as possible. I've been saved so many times by a git bisect that landed pointing at a tiny commit to a single line that looks completely innocuous, yet broke something in a subtle way that only got discovered way later. That's what source control is for, in my opinion. Finding stuff like that. So many of these things would have been really painful to find if I'd had to sift through every line of a big commit. So to watch people intentionally balling up an entire PR's worth of commits and squashing them together to throw away the only (in my mind) thing that version control is good for, is truly baffling. But yeah, there are plenty of people like the parent in that camp, so the author's plan to add even more granularity will be an uphill battle.

vbezhenar 4mo ago
> I've been saved so many times by a git bisect that landed pointing at a tiny commit to a single line that looks completely innocuous, yet broke something in a subtle way that only got discovered way later. I did git bisect exactly zero times in my life.
palata 4mo ago
> But yeah, there are plenty of people like the parent in that camp, so the author's plan to add even more granularity will be an uphill battle. I find it sad to see it as a battle. Can't we agree on the idea that different people may have different preferences? "Converting everyone to Linux or vim" would be an uphill battle... if it was worth fighting at all. I don't care what OS or text editor others use, as long as I can use the one that is best for me. If I am happy with commits, I don't want to fight with people who aren't... what would be the point?
foobarbecue 4mo ago
Github default squash commit template & merge strategy makes it easy to go from the squash commit to the feature branch. So you get best of both worlds -- clean master and granular history on the branch. Bisect on master tells you which branch broke it, and then bisect on the branch if you want to find the original commit. Same with blame. IMO squash 4 the win. Github squash defaults work well. Gitlab squash defaults don't.
- KajMagnus 4mo ago
  That's interesting, so you keep the branches from before the squash -- but do you also rename them somehow, to show that they're now "frozen historic versions"?
  - isleyaardvark 4mo ago
    That’s what I do, and I find this talk about “throwing away” code history baffling. It’s version control. Git branching is cheap. I make a ton of backup copies. I rearrange the history to how I want before I share it (git history split is great). I keep my nonsense, others see a readable changeset. (Only downside is the occasional housecleaning of old branches, but after a while their usefulness diminishes.)
  - foobarbecue 4mo ago
    Actually, what I usually do in Github is set the PR branches to delete when you squash-merge the PR, but then the PR always has an "undelete branch" button you can use forver in case you want to look at the details of the branch and don't have a local copy of the branch.
    - KajMagnus 4mo ago
      Interesting, didn't know about that Github functionality. I'd like to not depend that much on Github, and instead I'm thinking about having some kind of archival repo where noisy boring historical stuff can be saved (but I'd delete the branches in the main repo). Or renaming historical branches, eg adding an "old/" prefix.
skydhash 4mo ago
> So many people are so quick to throw away their history so that things look "tidy". It makes no sense, but somehow it fits a certain programmer-brain logic that is surprisingly common. I want my commits to reflect the evolution of the theory of the program, not a chronological log of my reflection and attempts. In my local branches I snapshot things that only matters to my working process. And before sharing, I make sure that the commits are atomic with a proper description. When sending a report, do you also send all the post-it, the notebook with your notes, the books with the highlights , your conversation with your colleagues, your web history? I don’t think you do. My local history have commits that reflect my working process which can be messy. Before sharing I tidy them, so that the changes are easily understood. > entire PR's worth of commits and squashing them together to throw away the only (in my mind) thing that version control is good for, is truly baffling A PR is supposed to be atomic if you’re using squash and merge. Bundling different changes is the antipattern here, not the squash and merge.
wvh 4mo ago
But do these intermediary commits run? I wouldn't mind making smaller commits, but usually wait until the changes result in a bunch of code that compiles and does what it should. It sounds as if you do checkpoints that don't necessarily result in working code or pass tests. Not that that is wrong, but it is a very different philosophy. I usually expect what I check out to compile and sort of work. I can't really pick up somebody else's train of thought midway.
danadam 4mo ago
> So many of these things would have been really painful to find if I'd had to sift through every line of a big commit. > So to watch people intentionally balling up an entire PR's worth of commits and squashing them together to throw away the only (in my mind) thing that version control is good for, is truly baffling. > But yeah, there are plenty of people like the parent in that camp I'm confused. The parent doesn't want big commits but rather, as they wrote twice, commits that are small, atomic and without noise. So presumably "fix typo" would be removed during rebase but "rename function" would stay and be separate from "implement logic".
- jasonkester 4mo ago
  I guess the difference between the parent and me is that I’ve been around long enough to see my share of “fix typo “ and “remove logging “ commits that accidentally removed the line above or below. That’s the commit I want to find six months later when the SVG text is blurry because we’re no longer forcing opacity to 1.0 at the end of a transition.

vbezhenar 4mo ago

> I've been saved so many times by a git bisect that landed pointing at a tiny commit to a single line that looks completely innocuous, yet broke something in a subtle way that only got discovered way later. I did git bisect exactly zero times in my life.

palata 4mo ago

> But yeah, there are plenty of people like the parent in that camp, so the author's plan to add even more granularity will be an uphill battle. I find it sad to see it as a battle. Can't we agree on the idea that different people may have different preferences? "Converting everyone to Linux or vim" would be an uphill battle... if it was worth fighting at all. I don't care what OS or text editor others use, as long as I can use the one that is best for me. If I am happy with commits, I don't want to fight with people who aren't... what would be the point?

foobarbecue 4mo ago

Github default squash commit template & merge strategy makes it easy to go from the squash commit to the feature branch. So you get best of both worlds -- clean master and granular history on the branch. Bisect on master tells you which branch broke it, and then bisect on the branch if you want to find the original commit. Same with blame. IMO squash 4 the win. Github squash defaults work well. Gitlab squash defaults don't.

KajMagnus 4mo ago
That's interesting, so you keep the branches from before the squash -- but do you also rename them somehow, to show that they're now "frozen historic versions"?
- isleyaardvark 4mo ago
  That’s what I do, and I find this talk about “throwing away” code history baffling. It’s version control. Git branching is cheap. I make a ton of backup copies. I rearrange the history to how I want before I share it (git history split is great). I keep my nonsense, others see a readable changeset. (Only downside is the occasional housecleaning of old branches, but after a while their usefulness diminishes.)
- foobarbecue 4mo ago
  Actually, what I usually do in Github is set the PR branches to delete when you squash-merge the PR, but then the PR always has an "undelete branch" button you can use forver in case you want to look at the details of the branch and don't have a local copy of the branch.
  - KajMagnus 4mo ago
    Interesting, didn't know about that Github functionality. I'd like to not depend that much on Github, and instead I'm thinking about having some kind of archival repo where noisy boring historical stuff can be saved (but I'd delete the branches in the main repo). Or renaming historical branches, eg adding an "old/" prefix.

skydhash 4mo ago

> So many people are so quick to throw away their history so that things look "tidy". It makes no sense, but somehow it fits a certain programmer-brain logic that is surprisingly common. I want my commits to reflect the evolution of the theory of the program, not a chronological log of my reflection and attempts. In my local branches I snapshot things that only matters to my working process. And before sharing, I make sure that the commits are atomic with a proper description. When sending a report, do you also send all the post-it, the notebook with your notes, the books with the highlights , your conversation with your colleagues, your web history? I don’t think you do. My local history have commits that reflect my working process which can be messy. Before sharing I tidy them, so that the changes are easily understood. > entire PR's worth of commits and squashing them together to throw away the only (in my mind) thing that version control is good for, is truly baffling A PR is supposed to be atomic if you’re using squash and merge. Bundling different changes is the antipattern here, not the squash and merge.

wvh 4mo ago

But do these intermediary commits run? I wouldn't mind making smaller commits, but usually wait until the changes result in a bunch of code that compiles and does what it should. It sounds as if you do checkpoints that don't necessarily result in working code or pass tests. Not that that is wrong, but it is a very different philosophy. I usually expect what I check out to compile and sort of work. I can't really pick up somebody else's train of thought midway.

danadam 4mo ago

> So many of these things would have been really painful to find if I'd had to sift through every line of a big commit. > So to watch people intentionally balling up an entire PR's worth of commits and squashing them together to throw away the only (in my mind) thing that version control is good for, is truly baffling. > But yeah, there are plenty of people like the parent in that camp I'm confused. The parent doesn't want big commits but rather, as they wrote twice, commits that are small, atomic and without noise. So presumably "fix typo" would be removed during rebase but "rename function" would stay and be separate from "implement logic".

jasonkester 4mo ago
I guess the difference between the parent and me is that I’ve been around long enough to see my share of “fix typo “ and “remove logging “ commits that accidentally removed the line above or below. That’s the commit I want to find six months later when the SVG text is blurry because we’re no longer forcing opacity to 1.0 at the end of a transition.