Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What comes after Git

matt-rickard.com

Post reply on HN
Print view View original

391–400 of 430 posts

Re: What comes after Git

#391

Post by 0xCAP »

nailer wrote: post #376
wvh wrote: post #361

Earlier quoted context omitted.

What's your alternative for stuff that needs to run on more than one server for reliability or scale? I have been duct-taping HA solutions since the late nineties, it definitely wasn't prettier than Kubernetes. We are beyond the phase where we want to care about a physical server with a broken hard disk or power supply. Whether or not Kubernetes-the-software is the answer to the conceptualisation of a "computer" is b…

> What's your alternative for stuff that needs to run on more than one server for reliability or scale? Same as most people, and as previously mentioned: I pay pay a cloud provider, unless my business is being a cloud provider.

How do you host your stuff on, say, GCP? App engine? Only 1 per project. Compute Engine? Basically a VPS. Cloud Run? Ok, good luck with stuff that requires long running requests or listening to events from a source different from Google Cloud Pub/Sub, because your instances are eventually going to scale down to 0 and not wake up if no HTTP requests are incoming, so basically not an options for microservices if you're rolling with a non-google event broker. Need to host other Kafka, Elastic search, or anything else non-trivially deployable? How do you do that?

Re: What comes after Git

#392

Post by IshKebab »

Aozora7 wrote: post #274
silisili wrote: post #66

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.

I completely agree. A GUI also lets you avoid the terrible CLI. Plus the commit graph is a visual thing. It makes sense to view it in a GUI.

Definitely the best way to learn.

Re: What comes after Git

#393

Post by tristan957 »

laurentlbm wrote: post #351
mikro2nd wrote: post #286

Earlier quoted context omitted.

Or there's sourcehut so you can use Hg. https://sr.ht

It's not as “accessible” though: it's not free and is less user-friendly.

During the alpha, SourceHut is free to use, except for builds.sr.ht, which was abused by crypto script kiddies.

I think you can pay as low as 2 dollars a month to use SourceHut.

Re: What comes after Git

#394

Post by jpgvm »

nailer wrote: post #323
jpgvm wrote: post #313

Earlier quoted context omitted.

Just no. 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…

You've said a lot of things but none of these respond to the comment you're referring to. > 1) Single-handedly forced the other 2 major vendors to implement a standard API. I (and I'm sure you too, you seem intelligent) would be surprised if say EKS is anywhere close to ECS usage. k8s is considered so complex/poor Amazon sell ECS-on-prem. It's the epitome of resume driven development - nobody uses k8s for any other r…

All of it responds to your original comment which was your statement that it contributed nothing except padded resumes.

I stated several things it contributed -even if you think it's too complex-.

If you don't understand why people use k8s you don't understand the problems it solves. Especially if you think ECS is a substitute.

Re: What comes after Git

#395

Post by sedatk »

throw-ru-938 wrote: post #148
sedatk wrote: post #26

Earlier quoted context omitted.

which is why I love Mercurial as it's immutable by default. You have to try really hard to mess up your repository.

Which is why I don't love Mercurial, because once you mess up your repo, it's messed up forever. IMO "easy to break but easy to fix" is better than "hard to break but impossible to fix", and there ain't no such thing as "hard to break" after enough time passes.

How do you mess up an immutable repository?

Re: What comes after Git

#396

Post by martinvonz »

ehnto wrote: post #164
R0flcopt3r wrote: post #153

Earlier quoted context omitted.

For you to enjoy using this tool you had to change the model your brain use, and you call that good UX? And using aliases means that your git is now different from you co-workers git. And when teaching the new guys you throw all these aliases at them that they have no idea what is or how work?

Is it really so hard to imagine a tool that takes some thought to use? I didn't know how to use a welder just by looking at it, but the UX is fine once you know the concepts behind welding. I honestly can't see how git could be easier given the requirments of the tool. If you want to reduce its capabilities because it's too hard then go ahead, but please fork it or make something new instead of ruining a perfectly go…

> I honestly can't see how git could be easier given the requirments of the tool.

If you're curious how it can be done (IMO), take a look at https://github.com/martinvonz/jj. It's its own VCS but also compatible with Git so individual developers on a team can migrate to it.

Re: What comes after Git

#397

Post by jpgvm »

emn13 wrote: post #191
skratlo wrote: post #181

Earlier quoted context omitted.

Came here to say this, I stopped reading after that, just skimmed the article, it's bunch of horsecrap.

To read this charitably, interpret that statement not to mean that kubernetes-the-software itself is the best gift to OSS collaboration ever, but rather that Kubernetes-the-project "brought open-source collaboration to a new level" in the context of working on kubernetes-the-software. I think that makes more sense, and certainly isn't as pompous.

OpenStack had similar levels of contribution at its peak and had much of the same solutions. I'm just guessing the author is newer to the game so might have missed out on 2010-2013 in the infrastructure space.

One of the cool things to come out of it was Zuul, which is a merge queue system similar to Bors and friends.

Re: What comes after Git

#398

Post by 8n4vidtmkvmk »

bvrmn wrote: post #311
capitainenemo wrote: post #297

Earlier quoted context omitted.

hg clean ? Actually, wait. hg up doesn't require network access. Maybe you're thinking of hg pull -u or svn up

> hg up doesn't require network access. So it's like `git checkout` and doesn't cover all breakage cases.

Dunno what scenario it would fail on. You can also clone a local repo as long as you didn't mangle the .hg dir

Re: What comes after Git

#399

Post by 8n4vidtmkvmk »

mbfg wrote: post #341
8n4vidtmkvmk wrote: post #111

Earlier quoted context omitted.

hg up --clean i dont know why mercurial doesn't get more love.

mercurial was pretty nice, and if you have a "beginner developer team", mercurial is probably my recommendation. but how git does branching is just better in a way you just can't get past, once you use it. Luckily it's usually pretty simple to start with hg and move to git at a later date.

Hg branching makes more sense to me. You can update to any changeset and then just start coding and it will naturally branch. If you want something more permanent you can create a named branch. If you can't find your unnamed branches you can bookmark or tag them.

Re: What comes after Git

#400

Post by avar »

flir wrote: post #281
avar wrote: post #258

Earlier quoted context omitted.

It stores a full copy of every node, not the diff. The diff is just something that's rendered on-demand, and "gc"/"repack" compaction and it being content-addressable makes sure that the storage space doesn't balloon as a result of everything being a full snapshot. This distinction makes a difference in some cases, there are other VCSs that store diffs as a fundamental property. About your naming suggestion: I'm not…

There are a lot of people, even in this comment section, whose internal model of git is "it's a tree". Langauge like "branch" reinforces that model, and I don't think it does beginners any favours in the long run. Something something leaky abstractions maybe? (Maybe you're right and I'm being a bit ivory tower here).

Even if you suppose that Git had some extreme UX overhaul to the point of renaming builtins like "branch", the existing names would still survive in the popular zeitgeist, as they predated Git.

So, I think it's an interesting thought experiment, but practically speaking a non-starter.

You'd never be able to fully migrate over, instead it would be another case of that xkcd about N standards.

Post reply on HN