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

Launch HN: Diversion (YC S22) – Cloud-Native Git Alternative

news.ycombinator.com

Post reply on HN
Print view View original

391–400 of 440 posts

Re: Launch HN: Diversion (YC S22) – Cloud-Native Git Alternative

#391

Post by atq2119 »

nojvek wrote: post #126

Git cli UX made be not great, but the git datastructure of representing commits, branches, trees and blobs as immutable pointers and merkle trees is a phenomenal invention. I don't agree with every command needs to hit some REST api. That seems like throwing the baby away with bathwater. The most powerful thing about git is that I can work fully offline with a partial clone. And sync the commits when I get online. Gi…

These SVN memories are why "cloud native" is an anti-feature to me. Most software, especially productivity software, should be offline-first.

Re: Launch HN: Diversion (YC S22) – Cloud-Native Git Alternative

#392

Post by withinboredom »

IshKebab wrote: post #338
withinboredom wrote: post #217

Earlier quoted context omitted.

If you’ve ever had to remove private information from history before making the repos public (think domains, names, configuration, etc) you will appreciate the ability to rewrite history (and all the other things --force gives you)

I don't get your point. Nobody is saying don't use `--force`. Just that the default `--force` flag is the most dangerous variant.

I am not aware of any default use of force. Where does that happen?

Re: Launch HN: Diversion (YC S22) – Cloud-Native Git Alternative

#393

Post by Arelius »

hasty_pudding wrote: post #333
Arelius wrote: post #298

Earlier quoted context omitted.

sigh So, in GameDev, art assets are as important to the final game as code. And is, just as important to be version controlled as code. And sure, you can split it up between many different repositories, and call it modular But you're just adding complexity, and not really solving the core problem which is that a single version of an art assets can possibly be > 1G, and be a poor format to be stored delta-encoded, so…

It's not rocket science to know that if you have a 1 TB git repo filled with massive binary files that all need to be version controlled, youre doing something VERY wrong or you are using the wrong tool. Literally the very first result on google search says almost every major game studio on earth uses perforce due to this specific problem because perforce allows you to check out binaries on a file to file basis and m…

> Perforce, as horrible as it is, is the game and VFX industry default for a reason

...

> or you are using the wrong tool.

You were literally responding to a comment talking about how git isn't suitable for this problem, and seemed to be suggesting that ec2 and a build script should be sufficient...

Edit: on a second full read, it's really unclear actually what your point was in the first place, And perhaps you were in agreement with the original poster and me all along, and just being confrontational and hostile for no reason?

Re: Launch HN: Diversion (YC S22) – Cloud-Native Git Alternative

#394

Post by Arelius »

maccard wrote: post #350
ryanlitalien wrote: post #347

Earlier quoted context omitted.

Hi, why the switch? Purely cost? Or admin overhead?

Yes, to both. P4 itself is solid, but it's a very chatty protocol and is very latency sensitive. Running a master in the us, with clients in europe is painful for everyone involved. Replicas and edge servers come with other tradeoffs too. As a developer, doing things like "I only want this subtree of the stream" is hard. Virtual streams exist, but they have a (non-negligible) overhead on the server. It has some quirk…

Agreed. It's also expensive, and support has been lacking. We'd much prefer something we could maintain and fix ourselves.

Re: Launch HN: Diversion (YC S22) – Cloud-Native Git Alternative

#395

Post by TexasMick »

lowbloodsugar wrote: post #385
TexasMick wrote: post #305

Earlier quoted context omitted.

It's kinda crazy argument, I think data loss is way more likely with a centralised system than a decentralised system.

You think Microsoft losing GitHub repos is more likely than poor bastards trying to make sense of the git command line? You think these guys are going to do a worse job with their centralized service?

People have lost data on GitHub from repositories being copyright striked for example.

At least with git, every developer has a copy of the full history so full data loss is impossible really. What happens if this company folds? You're left with some proprietary repo that you suddenly have to workout how to self host.

It just doesn't make sense when compared to just learning git which is definitely the most fruitful thing a developer could learn at the start of their career.

Re: Launch HN: Diversion (YC S22) – Cloud-Native Git Alternative

#396

Post by ffgjgf1 »

philsnow wrote: post #248
oblio wrote: post #116

Earlier quoted context omitted.

> Don't focus too much on "git complexity" as most people already know git so it just creates an argument. I'd say this phrase is both right and wrong. It's right in the sense that it creates an argument. It's wrong in that it creates an argument with the peanut gallery of git experts. But guess what, most people using git are not experts. They're software developers who don't want to learn the intricacies of git (pr…

> peanut gallery of git experts There are people who use git for its original purpose (kernel devs and very few others) and then there is the remaining 99% of people who essentially use “github flavored git”, using only three or four git subcommands and for the most part never needing to understand its intricacies. Unfortunately, although they are using git-the-chainsaw-shotgun with all the safeties on, it’s nonethel…

> If a new VCS can solve the 99% case and never need users to fall back to understanding nitty gritty details

Mercurial was a bit like that? Yet it didn’t stand a chance against git regardless

Re: Launch HN: Diversion (YC S22) – Cloud-Native Git Alternative

#397

Post by foofie »

jitl wrote: post #365
carlthome wrote: post #314

Earlier quoted context omitted.

Why not? Just want to understand.

Submodule workflows have a lot of overhead at review time. During development it's fine, you work with the fully materialized tree just like it's a monorepo. But once you need to submit your changes for review, how does that workflow look? 1. Commit in submodule A, then get it reviewed and merged as SHA 123 2. Update submodule A to 123, get it reviewed 3. Reviewer has feedback on usage of new API in submodule A 4. Ma…

> But once you need to submit your changes for review, how does that workflow look?

1. Post PR to submoduke A. Get it merged.

2. Post PR to the main repo updating it to point to subproject A.

Done.

The only difference between a monorepo and splitting the repo into submodules is that the main repo's history is coarser and basically tracks the output of integration tests. There is no need to overcomplicate things, and if you need to overthink them anyway then you have far more degrees of freedom to worry about in monorepos.

Re: Launch HN: Diversion (YC S22) – Cloud-Native Git Alternative

#398

Post by sasham »

oblio wrote: post #266
philsnow wrote: post #248

Earlier quoted context omitted.

> peanut gallery of git experts There are people who use git for its original purpose (kernel devs and very few others) and then there is the remaining 99% of people who essentially use “github flavored git”, using only three or four git subcommands and for the most part never needing to understand its intricacies. Unfortunately, although they are using git-the-chainsaw-shotgun with all the safeties on, it’s nonethel…

I see 2 huge barriers for a new commercial VCS: 1. Devs don't like to pay for core tools. And VCSes need network effects. 2. VCSes seem to be really hard.

Totally agree, it won't be easy. Companies do pay for GitHub/GitLab/Perforce though, and for indie devs there's the free tier. I think what made git really take off is actually GitHub's free tier/OS hosting, and not git itself being free (at least for parts of the market, and I might be wrong).

100% correct about VCS development, it's much harder than one can expect.

Re: Launch HN: Diversion (YC S22) – Cloud-Native Git Alternative

#399

Post by maccard »

Arelius wrote: post #394
maccard wrote: post #350

Earlier quoted context omitted.

Yes, to both. P4 itself is solid, but it's a very chatty protocol and is very latency sensitive. Running a master in the us, with clients in europe is painful for everyone involved. Replicas and edge servers come with other tradeoffs too. As a developer, doing things like "I only want this subtree of the stream" is hard. Virtual streams exist, but they have a (non-negligible) overhead on the server. It has some quirk…

Agreed. It's also expensive, and support has been lacking. We'd much prefer something we could maintain and fix ourselves.

Of all the complaints I have about p4, support is actually one I'm ok with. They've pretty consistently helped me fix issues over the years (plenty of which are bugs on their side that they have fixed after I raised it). Their sla is good, and their engineers are usually good at troubleshooting.

They are wildly, wildly expensive though.

Re: Launch HN: Diversion (YC S22) – Cloud-Native Git Alternative

#400

Post by weebull »

sasham wrote: post #297
hintymad wrote: post #282

> Cloud-Native Git Alternative Not sure if this is a good summary of the product. For one, cloud-native is an implementation detail, unless the company plans to sell the new VCS as packaged software instead of service. For two, I'm not sure how being cloud-native addresses any issue with my daily interaction with Git. > The biggest drawback of Git is its limited scalability I wonder how many people really has this pr…

Monorepos are indeed causing problems with git, and this is one of the main arguments against them (see [1]). Some companies are building their own solutions (Google, Meta), and some are splitting their monorepos because of these problems. IMO if a company wants to run a monorepo for their reasons, they shouldn't be limited by their VCS. The technical details are for the readers who want to know, I agree it's not rea…

Monorepos are a problem born of CI which can't cope with cross project dependencies properly. People have solved the problem by pumping everything together, but it's the wrong answer.

Fix CI and the problem goes away.

Post reply on HN