311–320 of 430 posts
Earlier quoted context omitted.
As I remember `hg up` requires network access. What if you break a repo offline?
hg clean ? Actually, wait. hg up doesn't require network access. Maybe you're thinking of hg pull -u or svn up
So it's like `git checkout` and doesn't cover all breakage cases.
How many people actually check that git has merged code correctly? When there are no conflicts and the merge passes CI? Exactly.
Now imagine the git automatically fixes conflicts by rewriting code Copilot-style. It will work perfectly 95% of the time—--so that new feature is too useful to ignore and everyone uses it. 5% of the time git resolves the conflict by riddling your code with subtle bugs and vulnerabilities…
>Nearly a decade later, new problems arose when Kubernetes (the operating system of the cloud) brought open-source collaboration to a new level. I'd love to get more context to that statement to understand it better because as it is, it sounds as such an arbitrary statement that undermines the credibility of all the content below. Kubernetes didn't brought open-source collaboration to a new level. No matter how relev…
Kubernetes main contribution to tech is “let’s do it all using kubernetes” as a meme for wasted time. It references the effort and money wasted by people that wanted to build cloud providers despite not being in the business of being a cloud provider.
Kubernetes has it's roots in Omega which was a research project to explore improvements to Borg.
It was created/released as a direct response to increasing lock-in of AWS and Azure PaaS like services that were becoming an existential threat to GCP ever gaining any marketshare.
Unlike OpenStack it did actually manage to mostly achieve it's goal of preventing lock-in by creating a standardized API in which all distributions/managed-providers need to provide and actually certifying that they do. OpenStack failed in this regard because it was overrun by vendor interests too quickly and suffered poor governance. Additionally the leading vendors of the time simply ignored it because none of them offered a compatible API layer and none of them cared about any of the upstarts that did. Also it turned out very few people wanted to build their own IaaS if it would be incompatible with AWS and bursting would be awkward.
k8s successfully learnt from these mistakes.
So it's contributions are two-fold.
1) Single-handedly forced the other 2 major vendors to implement a standard API.
2) Created an infrastructure OSS ecosystem above this API layer that broadly has been successful with enterprise interests while abiding by the governance model set out by core k8s.
These alone make it a very successful project even if you disagree with the technical implementation/merits.
Every time I use Git, I see how bad the UX is and marvel at how it ever became popular. Even a simple merge/rebase leaves one confused. Which should I use? What is incoming? Why does incoming change as you progress? I didn't change anything (on purpose) but Git won't let me change branches. What the hell does stashing do? How do I just unfuck what I did and go back to a branch? These are rather common use cases, and…
I find git reasonably understandable as long as you are using a GUI. When you have a GUI, every action you take provides you visual feedback, so it's way easier to understand the purposes of merges, rebeases, stashes, and resets. My understanding of git workflow greatly improved thanks to it.
>Nearly a decade later, new problems arose when Kubernetes (the operating system of the cloud) brought open-source collaboration to a new level. I'd love to get more context to that statement to understand it better because as it is, it sounds as such an arbitrary statement that undermines the credibility of all the content below. Kubernetes didn't brought open-source collaboration to a new level. No matter how relev…
Earlier quoted context omitted.
> marvel at how it ever became popular. It's worth going through old HN comment sections that have flamewars of SVN v git (or cvs vs hg or whatever) from 2006-2012 or so. The dvcs systems won because they changed a bad paradigm to one that's much much better - literally the way you think about version control these days is a radical departure from the previous way it was done. Merges are much much nicer in git then t…
But almost nobody actually uses git the way it was originally intended, eg. as decentralized version control? Instead there’s a canonical master repository (on GitHub) everyone pulls from/pushes to.
If you're going to collaborate in a decentralized way you ultimately need an accepted mainline source of truth.
Every time I use Git, I see how bad the UX is and marvel at how it ever became popular. Even a simple merge/rebase leaves one confused. Which should I use? What is incoming? Why does incoming change as you progress? I didn't change anything (on purpose) but Git won't let me change branches. What the hell does stashing do? How do I just unfuck what I did and go back to a branch? These are rather common use cases, and…
Use sourcetree (older versions) or smartigit(similar ui to sourcetree) if you are on linux Makes life a lot easier
Earlier quoted context omitted.
You don't need to learn its internals or read its code. You do need to learn what it does . This is not unreasonable, and is not the reason its interface is a mess.
Previous poster literally writes about implementation details. >You can, however, learn Git by reading about its architecture: blobs, trees, commits, pointers to commits (refs), and index (staging area where new commits are prepared). Impl details of e.g dbs, std libs, runtimes, compilers, etc are for advanced/expert cases, not for slighly above normal
Earlier quoted context omitted.
> marvel at how it ever became popular. It's worth going through old HN comment sections that have flamewars of SVN v git (or cvs vs hg or whatever) from 2006-2012 or so. The dvcs systems won because they changed a bad paradigm to one that's much much better - literally the way you think about version control these days is a radical departure from the previous way it was done. Merges are much much nicer in git then t…
But almost nobody actually uses git the way it was originally intended, eg. as decentralized version control? Instead there’s a canonical master repository (on GitHub) everyone pulls from/pushes to.