Docker is a scam.
Git is garbage.
The cloud is a scam.

I hate it all now.

Maybe I should try roofing.

You just outed yourself as not being a dev.

You are sortof right with the other two. But git is the most-loved dev tool ever made. It is so fucking good, that it finally unified the version control system landscape to use a single FOSS tool. It is easy to use, decentralized and ultra-reliable. It never gonna gives you up and never gonna lets you down - there almost always is a way to come back from a user error when using git. I used other version control systems before - git is the definitive best.

Docker a scam? It just does what it says.. no one is forced to use it.

Git is garbage? Ahmm.. sure.

Cloud is a scam? No, it's just an alternative to on-prem. Got the money to host in the cloud? Go for it. Got a OPS person/team to handle an on-prem hardware? Go for it.

Yep, maybe you should try roofing!

You'll just hate roofing too. Grumpy cat gotta be grumpy after all.

Just pick whatever makes you the most money since you won't be happy either way!

Grump gonna grump.
Totally get it, though.

@devdiddydog some companies went hard for docker without proper training, so yeah, some people were forced into devops knowledge without proper training or incentive for it. Git is awesome. Cloud IS a scam, in my side of enterprise, a fuckload of companies are moving into cloud only solutions which cost more money for companies. You did say "if you have the money for it" but there is a big difference between "maybe we can do this" to "y'all have no other option but go ahead and do this"

What’s wrong with git?

@Oktokolo And I've used many VCS's before Git too (SVN, SourceSafe, CVS, Perforce, ClearCase, CMVC) and Git is near the bottom of the pile as far as I'm concerned (above SourceSafe only, honestly).

It's a horribly overengineered mess that only won because of a cult of personality around its creator and the industry being sucked in by, basically, marketing (how many teams ACTUALLY need a DISTRIBUTED VCS? I'll give you the answer: not many).

Git is over-complicated beyond the most basic of operations and is confusing to developers even if they won't admit it.

"there almost always is a way to come back from a user error when using git"

...yes, and there has to be because errors happen A LOT with Git.

It also, for some weird reason, makes people think they need to use some NASA-ish branching strategy to "do Git right", which is likely an offshoot from its overengineered nature.

It's a clever implementation, sure, but that's about the only good thing I'll say about it.

@AleCx04 Exactly. There are choices. Cloud works for some, not for others. Same with docker. And Git, well that should just bloody work well for everyone!

The real scam was Kubernetes all along.

There's no such thing as the cloud, it's just someone else's computer

Docker is awesome, but if youre talking about docker*hub* i somewhat agree...

@Oktokolo imagine you're a newbie. Git is east, right? add, commit, push, yay...
Except you commited to a wrong branch and with something that should not be in a repo (password, key, whatevs). Before you realize your mistake, other colleagues add some extra commits.
Now, the learning curve to fix your fuckup + coordination, while making sure you dont break anything else is incredible..
I'm trying to use it, trying to learn it, but even after all those years I'm having issues recovering these situations

Obvious troll.

maybe you're just not qualified to use computers?

You could buy kneepads...

@kiki already drumphed by RHEL Openshift...

@fzammetti Every project I ever saw that was too small to benefit from distributed VCS lacked the proper processes and backups to safely use centralized VCS. The distributed nature of Git actually works better the less principled you are, because it makes recovering using a valid dev machine from data loss caused by force-pushes about as complicated as renaming a branch.

@qwwerty The problem you describe exists for all version control systems as preserving history is their primary goal.

But in git you at least can change that history after the fact. The commands are obscure but at least the most common cases are covered by the official docs at https://git-scm.com/book/en/...

It is still a pretty decent walk of shame for the noob as probably everyone has to push his current branches and recheckout after the rewrite (because it actually changes the history including hashes). But at least it's possible with git. For an accidentally committed and pushed password i would likely still just change that password instead of rewriting history though.

@fzammetti Basic operations is all you need in all but one day per year if you are the one who is actually permitted to do the non-basic operations.

You can use git perfectly fine with an IDE that has a GUI for it. Don't have to memorize commands and arguments. And i recommend having one production, and a staging and a developing branch and then everyone does his work in another branch that is theirs alone and which they can do with whatever they want and nobody else uses. Work that's done is rebased onto the developing branch and then merged into it (if you want, you can do pull requests, but that's often just overkill for proprietary projects). Someone then merges the development branch to staging and eventually staging to production (both steps can be automated with CI tools, but don't have to).

That git is distributed by default doesn't matter at all. You can use it local only if you are just making a Factorio mod...

@devdiddydog the git part got me too. Also git complains really do boil down to "I do not understand what I am doing" and we can both argue the same for docker (both are still awesome imho) and cloud is not bad, I just dislike companies not giving in premise options for the clients.

@Oktokolo The reason being distributed is bad... and I see it over and over again with average developers... is that the mental model is more complicated than it needs to be. Git is fine when nothing goes wrong. But when it doesn't:

"Why aren't my changes in the repo, I committed them!"

"Oh, the commit worked, but the push failed because I didn't include a valid Jira ticket in the commit message and the hook rejected it, what do I do now because my IDE is showing me nothing to do?"

"Rest HEAD? What does that mean? Why do I have to? Oh, just do it because it works for some reason and don't worry about understanding? Okay then."

Things like this happen ALL THE TIME, and we're not talking about the world's worst developers here.

It's ironic that Git is the ONE tool developers are happy to be FORCED to understand to use effectively while most others they're happy to just ignorantly let the magic happen (cra, ng, Spring, Maven, etc.)

@fzammetti @TeachMeCode

Overly complicated plumbing creates horrible user interfaces.

Any tool that requires me to work “around” it should be redesigned.

@Grumpycat @TeachMeCode

I have never seen git used the same way at several different companies. I would argue that something that flexible requires too much of a learning curve. What branching strategy are we using this week?

@tosensei

Which computers? The combinatorial explosion of ridiculous options has overwhelmed my puny brain. Wait a second I am running an update that is going to fuck up my registry and then fuck up the /etc folder too. But first the hypervisor is going to crash because my bios options are not set correctly. Fuck me.

@fzammetti You can actually just amend the commit to alter the message to include the ticket ID and then push again.

@TeachMeCode

You have never seen a senior dev stroke out over auto.crlf have you?

@TeachMeCode

What is right about it? Wrong question.

@NeatNerdPrime @Oktokolo

When you spend more time dealing with git problems than writing code you begin to wonder if it is actually worth it.

@Grumpycat Exactly.

@Oktokolo I know... but you'd be surprised how many devs I've seen get totally flummoxed by that situation.

sudo rm .git

Problem solved start over.

@fzammetti Sure, they do. And then they learn how the tool works and suddenly everyday tasks are trivial.

@Grumpycat When you spend more time with git problems than writing code, you or your team mates are actually code monkeys - not devs.

That said, you can teach code monkeys how to do the everyday git workflow quite easily. As they never work on code other people work on at the same time, they never get a rebase conflict and their memorized sequence of clicks (assuming IDE integration) just works every time.

@Oktokolo

And magical fairy dust flows all around the git fanboys. Its a beautiful thing.

@Oktokolo game devs use some fucked up tool for version control called perforce. I wish everything unified under git. 😕

@Nanos AFAIK they switched from git to plastic which they bought a while ago.

@gagan-suie sadly git for game dev is horrible since gits biggest drawbag is binary management. Lfs can remedy some of the problems but hosting that gets expensive fast or is a total pain to setup/maintain.

@crafter right, I've experienced some of the pains. But I'm hoping git +AI can solve these issues soon.

@TheBeardedOne

For which you must pay for the privilege of using said other computer.

@qwwerty there is a reason the “commit” command is names as such.
This is why we have “add” and “commit” separately.

The way I see it, it is expected that when a person “commits”, they have done their due diligence and are only committing explicitly verified things.

Then, there are PRs so that commits can be reviewed before some “newbie” can add random insecure stuff in any branch. Newbie must create bugfix/ or feature/ branch, make changes, and raise a PR. Direct changes by newbies are not expected.

There is a tool, and then there is a process around it. One cannot take a chainsaw, dance around with it flouting all guidelines, and then claim that the chainsaw is unsafe and beginner friendly.

@nanobot You're operating on an assumption the newbies are onboarded into established process - with branching model, PRs, guidelines, etc... Unfortunately for us, that is not the case. We have no senior programmer with SCM system experience in our team.

e.g. chainsaw example - Imagine you're given one, but never operated it nor seen anyone do it. You've heard it can help you and make your life easier, so you go through manuals and instructional videos where everyone tells you how easy and awesome it is, but in the end few close calls/lost fingers/ER visits or broken chainsaw are often unavoidable costs in "learning by doing".

@qwwerty i do see your point.

So the catch is having the process if we want to use the tool.

@nanobot Correct, but the catch is you need someone with experience to set the process correctly. (...and within the corporate limits)

I.e. anyone can make up some process based on random internet info, but if it's set incorrectly and cause issues, it'll slow SCM adoption as people will hate it and won't see the benefit.

People hating on git for being too complex while k8s is sitting in the corner hoping nobody notices...