Coming from CVS and ClearCase it took me some time to adopt to Git. The fact that it was distributed was confusing at first, for example, because I thought that would cause chaos. But the way we used it was actually not “that distributed”. But once I understood how it worked, not doing DVCS was “the wrong way” immediately.
You must log in or register to comment.
I’ve only worked in software for about 15 years, so don’t have much experience outside of git.
But my first job used Microsoft Team Foundation, and I didn’t need any experience to know that user experience sucked. I’ve also done the “date named zip file” type of version control, which is not ideal.
When I started using git it just made sense to me, have had no major complaints since.
I’ve been using Git professionally as a software developer for 15 years, and I think it sucks quite hard. There is always a dosen ways to do the same thing, it occupies tons of hardware space, it’s log is unstructured data that has to be parsed. Git CLI is an incomprehensible mess of bloat and misnomers, so no matter what team/project you are working on, there is always going to be 1-5 Git commands they’ll tell “you are NEVER supposed to use”.
I’ve completed my courses on Git, I’ve worked with CI/CD, onboarded younger developers, read “Git Koans”, and I haven’t seen even a theoretically convenient VCS until someone showed me Pijul.
Git is mess, it sucks that we are stuck with it, and every time someone says it’s the best VCS we have, it saddens me.
Having used SCCS, RCS, CVS, SVN and then Git - like a progression of successive added features - as well as clearcase, I find the biggest difference when stepping up to git was the flinging of patchballs via the push mechanism.
I like how every working dir is really kinda a repo, and the ability to pick back into a repo from a suitably rich checkout has been a life-saver from time to time.
Having marshalled my own builds by hand or by cron, I do like the CI stuff in gitlab to trigger CIs and CDs; but the stuff in forgejo and GitHub can go to hell without any supper. Enough goddamned YAML, please.
As I think of projects I recently ditched before I started playing with CI, too, I almost want to pick them back up. We talk on another thread about the wasting death of good projects because the greybeards are dying and the kids dont have the time and clue to pick up after them, but maybe this automation will help them to keep maintaining their stuff (and someone else’s) just a bit longer.
Git is good things. Clearcase was awesome but IBM destroyed the best company I ever worked for and bought Rational and withheld licenses while doing so, so they and clearcase can die in the same firey hell as YAML.
How did it change how I think about version control? Not much? The goals are still the same. It only does many things better than previous centralized tools.
When DVCS came up and became popular, I used Git and Bzr.
At work, we used subversion. In one project, we had one SVN repository in our office and the customer had one in their office. A colleage had created a sync util. We regularly synced all history into an external hard drive, drove to the customer, and merged it there. Required a thorough and checklist process, potentially conflict resolution, and changelog generating for the big merge commit. Then drive back to the office, and merge back there.
Of course sometimes you used remote desktop to hotfix changes in their code base. Meaning you’d now have the change in two places as different commits.
Anyway, I’ve never found Git difficult. I used it, learned and understood it, and it’s consistent. I know enough “internals”/technical details to understand and use it well and without confusion.
As an ancient ops person, I was unfamiliar with version control before git. So git has really changed how I look at look at version control!
Local vcs let’s you decouple saving progress (commit) from publishing your change (push).
This is a huge improvement over exclusive locks (old visual source safe) and shared server (like perforce).
There are many other improvements, but that is the one that had the most impact on my daily workflow.
I had a sad incident where I had committed changes but not pushed, and then I accidentally spilled a drink on my computer and bricked it. Even though this is unlikely to happen again because I won’t bring open containers like mugs or bowls of soup around computers anymore (water bottles are fine), and it was only three hours of work lost, because of this incident I do not feel I have saved until I have pushed. “What if you brick your computer again, huh, where’s all that progress now?”
But overall I agree about decoupling saving changes from actually publishing them!
The staging area changed the way I work for the better. When I develop something, a file can be at the same time “not modified yet,” in progress where I can carefully accept or reject the modifications, and partially done when the parts have been confirmed and added to the staging area.
Once nothing is “in progress” anymore, I know that my future commit is almost perfect and I can quickly review my stuff before committing. It’s faster and more safe than other tools.
Too new to have come from older vcs, but I can tell it’s a clear improvement over zip files.
