6 ms·

Great to see a chapter on version control. It is such a shame that almost no CS program teaches proper version control. VCSs and the commit history can be such

Great to see a chapter on version control. It is such a shame that almost no CS program teaches proper version control. VCSs and the commit history can be such a tremendously valuable tool when used correctly. git bisect/blame/revert/rebase/… become so much less useful when VC is treated as a chore and afterthought, and basically amounts to: “Feature is done, my work is complete, just do `git commit -am "changes"` and be done with it.”. And don’t get me started on commit messages. It is shameful that for a large part of the industry, this is the norm. It is shameful that for a lot of professional, who call themselves software architects or reliability engineers and such fancy titles, still have essentially no idea what they are doing with git, and their response when git add/commit/push/pull don’t work is to shrug, and just delete and re-clone the repo. Version control should be treated with care and attention to detail. It pays for itself 100 times over. If your commit history is maintained and tells a story, it is a joy to review your PR. If you just `git commit -am "try fix"` 26 times over, and all that is left in the end is a ball of mud, it is horrible.

TonyStr 8mo ago
It seems most people learn git only through necessity. I've heard people say "I just want to code, I don't care about the peripherals". JIT learning is a good way to acquire capabilities with real-world application, but there is not JIT pull that forces people to learn about bisect, git objects, git logging, etc. These things can only be learnt either through setting off time to read documentation or by being taught through a course. I think this is a good argument for teaching git, and being thorough in doing so, as many people are likely to never take that initiative themselves, while the benefits to being good at git are so obvious.
- Anonyneko 8mo ago
  I think most people learn git through the particular processes that are established at their workplace, as every company uses git or VCS in general differently somehow.
- stackghost 8mo ago
  >It seems most people learn git only through necessity. I've heard people say "I just want to code, I don't care about the peripherals" I'm sure there's an element of (intellectual) laziness too, but I think people tend to only learn git by necessity because git is simply unpleasant to use. A lot of us have Stockholm syndrome because git is less bad than what came before it, but git is not good.
- skydhash 8mo ago
  I see this enough that I don’t bother ranting about it. There’s the free “Pro Git” (on the git homepage) that will teach you most of what you”ll need in a lifetime. But you tell people about rebase and the reflog and their eyes glaze over.
npinsker 8mo ago
This feels harsh. Engineers have an endless list of other things to learn that are arguably more important, and it isn’t always worth understanding all the weird edge cases that almost never pop up (to say nothing of Git’s hostile, labyrinthine UX that one would have to deal with).
- gcr 8mo ago
  It's absolutely worth taking the time to learn `jj`, for example, but `jj`'s ideas build on top of `git`'s ideas. If you don't know why it's important that commits reference their parents, for example, that's limiting your knowledge of how VCS works in important ways. A compromise/synthesis: everyone should absolutely learn how git works internally, but not necessarily how to use the git-specific porcelain/tooling/CLI
- HelloNurse 8mo ago
  What things to learn are more important for "engineers" than using VC messages and history for communicating adequately (including communicating with themselves in the future) and using VC merging, staging etc. to put source code in a good state that they intend to build, share and archive? Irreproducible or incomprehensible work is worse than nothing.
  - 9dev 8mo ago
    That’s akin to saying the most important thing for an author is to use a word professor correctly.
    - irishcoffee 8mo ago
      I'd argue its like saying its important for an author to write an entire book using ed.
xml 8mo ago
If most people are not using a tool properly, it is not their fault; it is the tool's fault. Git is better than what came before, and it might be the best at what it does, but that does not mean that it is good. - The interface is unintuitive. - Jargon is everywhere. - Feature discoverability is bad. - Once something goes wrong, it is often more difficult to recover. If you're not familiar enough with Git to get yourself into that situation, then you certainly aren't familiar enough to get yourself out of it. Many of those issues are due to git being a command line interface, but others (like no general undo and funny names) are simply due to bad design. I think it is about time that we try again and build a better version control tool, but maybe git is just too entrenched.
- krupan 8mo ago
  Very true, though it has improved a over the years. Most people haven't noticed because when git has introduced newer simpler commands it hasn't deprecated the old ones. You can now use it like this, but most people don't know it: git switch some-branch # edit files git restore file2 # undo changes to file2 git stage file1 git commit Instead of the old workflow using checkout with a bunch of different flags. I agree though that git is needlessly obtuse. I advocated for mercurial instead of git for years because mercurial was so much more user friendly, but git won. I hear good things about jj now
- cameronh90 8mo ago
  > If most people are not using a tool properly, it is not their fault; it is the tool's fault. This is a standard that we don't apply to most other tools outside of IT. I do think git could be more usable, but most powerful tools have sharp edges and require training. A bandsaw is a fantastic tool, but if you try to use one without reading about it first, you'll end up losing a finger. I'm not sure I'd blame the bandsaw in that instance...
  - fragmede 8mo ago
    Then again, the number of shop teachers missing a finger would give anybody pause. Blame is secondary to the fact that you just lost your fucking finger. Thankfully, git's sharp edges won't permanently physically maim you, though guts sharp edges resulting in you committing API keys GitHub can still hurt you, just in your wallet but at least you didn't lose a finger.
krupan 8mo ago
So much this. Once you get beyond the very basics, git is a code editing tool as much as your editor/ide is
sigbottle 8mo ago
I have heard of each of those tools but I've never really used them for real. Like, I attempt to write good commit messages and stage my changes in such a way that the commits are small, obvious, and understandable. That's about it. But the advanced tooling around git is scary ngl.
- oytis 8mo ago
  My rite of passage towards git kung-fu was committing to Linux kernel. It's brutal there, you have to have your history really clean. Meanwhile enterprise teams are often like - who cares, let's auto-squash all commits into one.
sh34r 8mo ago
Your workflow makes sense for FOSS projects, where the commit is the unit of work. In my experience, on most professional teams, the PR is the unit of work. PRs trigger CI/CD pipelines. PRs map to tickets. The meaningful commit goes with the squash merge to the shared dev/main branch. There are cases where I've staged commits this way for a PR, to make it more reviewable. I'd usually rather split them off into separate PRs, but when that would create a pipeline of three MRs that are meaningless on their own, then rewriting history for a single MR makes sense. I generally consider my feature branch's commit history to be for me, not for you. Going back and rewriting history is a chore that shouldn't be necessary if I did a decent enough job with the PR description and task decomposition. Those commits are getting squashed anyway. Along with all the "fix MR comments" commits on top of it. It wouldn't bother me to adopt your workflow if it fits your team and its tools and processes. I'd just say, consider that your way isn't the only correct way of doing things. Your preferences are valid, but so are others'. The only thing that really bothers me is absolutism. "My way or the highway." Your writing here reminded me of a particularly unpleasant coworker I had in the past. I quickly browsed your comment history to make sure you're not him... Excessive rigidity is not an endearing quality. All that being said, I have also been constantly annoyed by people with too many YoE who can't be bothered to spend an hour or three to learn the basics of how the Git tree is structured, and what merge vs rebase does. They rely too heavily on their GUI crutches and can't fix anything once it goes sideways. Even when you lead them to water, sending them reading material and offering to answer questions after, they refuse to drink. Willful ignorance is far more irritating than stubbornness. I don't expect them to be able to remember what bisect vs cherry-pick does. Claude will spit out the subcommands for them if they can describe what they need in English. But they can't do that if they have no understanding of the underlying data structures...
- deleted 8mo ago
  [deleted]
Stevvo 8mo ago
"Almost no CS program teaches proper version control" This is just false. In the UK, you would learn version control in the first week, then submit all work through version control for the whole course. I find it hard to believe that Americans just don't use version control at school. It doesn't make any sense.
- Hendrikto 8mo ago
  > It doesn't make any sense. Exactly. But that is sadly the state of things.
barnacs 8mo ago
I don't think using git should necessarily be taught as a part of a CS education. Any self respecting engineer will be capable and have the curiosity and motivation to dig into it on their own. CS should give them the prereqs to do so, such as hashing, graphs, trees, etc.
AnimalMuppet 8mo ago
Version control isn't the only thing like that (though it might be the most important). They ought to have some familiarity with the idea of a bug database, for example. A requirements database (a software engineer could go through their entire career without having to ever touch one, but they should be familiar with the idea).
esafak 8mo ago
This might be a good time to teach jujitsu, before they're too invested in git.
zerkten 8mo ago
A big part of the problem is being permitted to teach this stuff. As a UK CS grad from the early-2000s, my observation was that academic staff recognized the need for these skills. They weren't permitted to teach it due to time available and the view that it wasn't academic. Thankfully, my university's CS department offered courses in these kinds of topics taught by the support staff (read: sysadmins). These courses existed to help other departments with skills but were open to students. Fast forward twelve years and my wife did the MCIT at UPenn (https://catalog.upenn.edu/graduate/programs/computer-information-technology-mcit/ https://catalog.upenn.edu/graduate/programs/computer-informa...) where git and other topics woven into the curriculum. Even then, they were perhaps a novelty because their focus was bringing non-CS undergrads into a CS Masters program. So-called "conversion" master's degrees were the norm in the UK in 2002.

TonyStr 8mo ago

It seems most people learn git only through necessity. I've heard people say "I just want to code, I don't care about the peripherals". JIT learning is a good way to acquire capabilities with real-world application, but there is not JIT pull that forces people to learn about bisect, git objects, git logging, etc. These things can only be learnt either through setting off time to read documentation or by being taught through a course. I think this is a good argument for teaching git, and being thorough in doing so, as many people are likely to never take that initiative themselves, while the benefits to being good at git are so obvious.

Anonyneko 8mo ago
I think most people learn git through the particular processes that are established at their workplace, as every company uses git or VCS in general differently somehow.
stackghost 8mo ago
>It seems most people learn git only through necessity. I've heard people say "I just want to code, I don't care about the peripherals" I'm sure there's an element of (intellectual) laziness too, but I think people tend to only learn git by necessity because git is simply unpleasant to use. A lot of us have Stockholm syndrome because git is less bad than what came before it, but git is not good.
skydhash 8mo ago
I see this enough that I don’t bother ranting about it. There’s the free “Pro Git” (on the git homepage) that will teach you most of what you”ll need in a lifetime. But you tell people about rebase and the reflog and their eyes glaze over.

npinsker 8mo ago

This feels harsh. Engineers have an endless list of other things to learn that are arguably more important, and it isn’t always worth understanding all the weird edge cases that almost never pop up (to say nothing of Git’s hostile, labyrinthine UX that one would have to deal with).

gcr 8mo ago
It's absolutely worth taking the time to learn `jj`, for example, but `jj`'s ideas build on top of `git`'s ideas. If you don't know why it's important that commits reference their parents, for example, that's limiting your knowledge of how VCS works in important ways. A compromise/synthesis: everyone should absolutely learn how git works internally, but not necessarily how to use the git-specific porcelain/tooling/CLI
HelloNurse 8mo ago
What things to learn are more important for "engineers" than using VC messages and history for communicating adequately (including communicating with themselves in the future) and using VC merging, staging etc. to put source code in a good state that they intend to build, share and archive? Irreproducible or incomprehensible work is worse than nothing.
- 9dev 8mo ago
  That’s akin to saying the most important thing for an author is to use a word professor correctly.
  - irishcoffee 8mo ago
    I'd argue its like saying its important for an author to write an entire book using ed.

xml 8mo ago

If most people are not using a tool properly, it is not their fault; it is the tool's fault. Git is better than what came before, and it might be the best at what it does, but that does not mean that it is good. - The interface is unintuitive. - Jargon is everywhere. - Feature discoverability is bad. - Once something goes wrong, it is often more difficult to recover. If you're not familiar enough with Git to get yourself into that situation, then you certainly aren't familiar enough to get yourself out of it. Many of those issues are due to git being a command line interface, but others (like no general undo and funny names) are simply due to bad design. I think it is about time that we try again and build a better version control tool, but maybe git is just too entrenched.

krupan 8mo ago
Very true, though it has improved a over the years. Most people haven't noticed because when git has introduced newer simpler commands it hasn't deprecated the old ones. You can now use it like this, but most people don't know it: git switch some-branch # edit files git restore file2 # undo changes to file2 git stage file1 git commit Instead of the old workflow using checkout with a bunch of different flags. I agree though that git is needlessly obtuse. I advocated for mercurial instead of git for years because mercurial was so much more user friendly, but git won. I hear good things about jj now
cameronh90 8mo ago
> If most people are not using a tool properly, it is not their fault; it is the tool's fault. This is a standard that we don't apply to most other tools outside of IT. I do think git could be more usable, but most powerful tools have sharp edges and require training. A bandsaw is a fantastic tool, but if you try to use one without reading about it first, you'll end up losing a finger. I'm not sure I'd blame the bandsaw in that instance...
- fragmede 8mo ago
  Then again, the number of shop teachers missing a finger would give anybody pause. Blame is secondary to the fact that you just lost your fucking finger. Thankfully, git's sharp edges won't permanently physically maim you, though guts sharp edges resulting in you committing API keys GitHub can still hurt you, just in your wallet but at least you didn't lose a finger.

krupan 8mo ago

So much this. Once you get beyond the very basics, git is a code editing tool as much as your editor/ide is

sigbottle 8mo ago

I have heard of each of those tools but I've never really used them for real. Like, I attempt to write good commit messages and stage my changes in such a way that the commits are small, obvious, and understandable. That's about it. But the advanced tooling around git is scary ngl.

oytis 8mo ago
My rite of passage towards git kung-fu was committing to Linux kernel. It's brutal there, you have to have your history really clean. Meanwhile enterprise teams are often like - who cares, let's auto-squash all commits into one.

sh34r 8mo ago

Your workflow makes sense for FOSS projects, where the commit is the unit of work. In my experience, on most professional teams, the PR is the unit of work. PRs trigger CI/CD pipelines. PRs map to tickets. The meaningful commit goes with the squash merge to the shared dev/main branch. There are cases where I've staged commits this way for a PR, to make it more reviewable. I'd usually rather split them off into separate PRs, but when that would create a pipeline of three MRs that are meaningless on their own, then rewriting history for a single MR makes sense. I generally consider my feature branch's commit history to be for me, not for you. Going back and rewriting history is a chore that shouldn't be necessary if I did a decent enough job with the PR description and task decomposition. Those commits are getting squashed anyway. Along with all the "fix MR comments" commits on top of it. It wouldn't bother me to adopt your workflow if it fits your team and its tools and processes. I'd just say, consider that your way isn't the only correct way of doing things. Your preferences are valid, but so are others'. The only thing that really bothers me is absolutism. "My way or the highway." Your writing here reminded me of a particularly unpleasant coworker I had in the past. I quickly browsed your comment history to make sure you're not him... Excessive rigidity is not an endearing quality. All that being said, I have also been constantly annoyed by people with too many YoE who can't be bothered to spend an hour or three to learn the basics of how the Git tree is structured, and what merge vs rebase does. They rely too heavily on their GUI crutches and can't fix anything once it goes sideways. Even when you lead them to water, sending them reading material and offering to answer questions after, they refuse to drink. Willful ignorance is far more irritating than stubbornness. I don't expect them to be able to remember what bisect vs cherry-pick does. Claude will spit out the subcommands for them if they can describe what they need in English. But they can't do that if they have no understanding of the underlying data structures...

deleted 8mo ago
[deleted]

Stevvo 8mo ago

"Almost no CS program teaches proper version control" This is just false. In the UK, you would learn version control in the first week, then submit all work through version control for the whole course. I find it hard to believe that Americans just don't use version control at school. It doesn't make any sense.

Hendrikto 8mo ago
> It doesn't make any sense. Exactly. But that is sadly the state of things.

barnacs 8mo ago

I don't think using git should necessarily be taught as a part of a CS education. Any self respecting engineer will be capable and have the curiosity and motivation to dig into it on their own. CS should give them the prereqs to do so, such as hashing, graphs, trees, etc.

AnimalMuppet 8mo ago

Version control isn't the only thing like that (though it might be the most important). They ought to have some familiarity with the idea of a bug database, for example. A requirements database (a software engineer could go through their entire career without having to ever touch one, but they should be familiar with the idea).

esafak 8mo ago

This might be a good time to teach jujitsu, before they're too invested in git.

zerkten 8mo ago

A big part of the problem is being permitted to teach this stuff. As a UK CS grad from the early-2000s, my observation was that academic staff recognized the need for these skills. They weren't permitted to teach it due to time available and the view that it wasn't academic. Thankfully, my university's CS department offered courses in these kinds of topics taught by the support staff (read: sysadmins). These courses existed to help other departments with skills but were open to students. Fast forward twelve years and my wife did the MCIT at UPenn (https://catalog.upenn.edu/graduate/programs/computer-information-technology-mcit/ https://catalog.upenn.edu/graduate/programs/computer-informa...) where git and other topics woven into the curriculum. Even then, they were perhaps a novelty because their focus was bringing non-CS undergrads into a CS Masters program. So-called "conversion" master's degrees were the norm in the UK in 2002.