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

411–420 of 440 posts

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

#411

Post by sasham »

__turbobrew__ wrote: post #202
nine_k wrote: post #144

Earlier quoted context omitted.

The number of concurrent merges is definitely a problem. With a few hundred developers committing to the same repo all day, it becomes a chore to make sure that their commits can still be put on top of each other, and that one out-of-sync commit is not holding back a bunch of others which depend on it. This all is solvable, both through discipline and tools. But if a VCS has a built-in capability to alleviate this, i…

The solution to that problem is a merge queue and GitHub supports that now. I do agree that it would be nice if the VCS solved the problem natively, but for many companies GitHub — and not git — is their VCS.

Exactly.

The number of companies that implemented their own merge queue is too damn high.

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

#412

Post by withinboredom »

sasham wrote: post #403
withinboredom wrote: post #253

Earlier quoted context omitted.

My understanding from reading much of OPs responses is that “the cloud” may be vendor locked to AWS. There are serious issues there to hosting your code on servers most likely owned by a competitor. E-Commerce, video streaming, games, AI, video production, electronics, retail, pharmaceuticals, logistics, publishing, etc. Like they literally picked the worst vendor to build this on.

Why the worst? Microsoft is a more serious competitor to game studios with Xbox Game Studios and now Activision Blizzard. (And yet they do use Azure). You definitely have a point reg vendor lock, we've planned for this and Diversion will be able to run in any cloud and on-prem in the future (we are running it in containers now).

Worst due to spread. Almost any industry Amazon has a hand in means you might run into issues selling in that industry.

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

#413

Post by sasham »

casercaramel144 wrote: post #167

Congrats on the launch! It's always exciting to see more competition in the version control space. One question I have is whether you guys are better than: https://desktop.github.com/ This seems to do the exact same thing, be free forever, and have a more mature GUI that is also easier to use than regular terminal git. In my firm, even with people who don't know how to code, they can use github desktop (since it babi…

Thanks! I like GH Desktop as well, as a matter of fact our Web UI is a bit influenced by it :) The difference is that GHD is a GUI for git. It's quite good in hiding some of the complexity, but if you get a git error (like a diverged branch) you still need to troubleshoot it. Diversion is completely different. 1st of all it's far less complex, without local branches, staging area, etc. It also syncs your work in progress to the cloud in real time, alerts users about potential conflicts, handles large files without extra configuration, etc. Feel free to try it! (It's also free forever for small teams).

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

#414

Post by sasham »

i-use-nixos-btw wrote: post #375

Constructive criticism. I would like to see much, much more in a demo. Probably around 20-30 minutes. What was shown in the demo video was seemingly the functionality of Dropbox, shown working with one file manager and one OS. I know it is more than that. I’ve checked your docs. You have branching models. You have cross OS support. You have a lot going on. But that demo video really put me off. It doesn’t demonstrate…

Thanks for the feedback! Point taken.

The intro video is really just scratching the surface, you're right. We'll post more in-depth videos soon.

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

#415

Post by Arelius »

ryanlitalien wrote: post #402
maccard wrote: post #399

Earlier quoted context omitted.

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.

That totally depends on where you put value. We're a fraction of other companies licenses for comparison. Also, we have new pricing for our new Helix Core Cloud SaaS product!

Yeah. New pricing, but not cheaper. Don't get me wrong. It's a fine price to pay for a studio going strong. But there is no way I can use it for starting my side-project indie game.

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

#416

Post by hasty_pudding »

esafak wrote: post #389
hasty_pudding wrote: post #223

Earlier quoted context omitted.

why is it about time?? VCS is sort of a solved problem like SQL. it's like saying it's about time someone revisited those Javascript frameworks.

I don't know about that. The UX of git leaves a lot to be desired. monorepos and large files are not definitely solved, either. If not git, what solution did you have in mind?

millions of repos on github don't have those issues.

Youre talking an extreme use case. Like saying we need to replace the shovel because it cant do what a bulldozer does.

Its miniscule fraction of GitHub repos have those issues like an incredibly small number mainly devoted to games or media.

UX is fine if you know it. SQL UX isnt ideal either.

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

#417

Post by NateEag »

xorcist wrote: post #321
NateEag wrote: post #272

Earlier quoted context omitted.

That all makes sense and mirrors many of my own thoughts. Though I'll say that "--force" isn't necessarily a "scary-sounding" option name unless you're used to Unix CLI naming conventions. Further, the warnings git gives you about this are virtually inscrutable if you don't already understand what's happening. A good interface to "blowing away history" would give you a brief summary of what will actually be gone, e.g…

> Are you SURE you want to completely destroy those commits? (Y/n) While there is a lot of user interfaces that could be improved, I believe the above have empirically been shown to be inferior to the alternative "re-run this command but add scary option to proceed". Users habitually answer "Y" to questions like the above all the time. And certainly after a few times it becomes routine for anyone. But having to re-en…

You make a good point about "Y/n" being more dangerous than refusing and requiring an explicit option be passed.

The clear warning about what commits will be lost is not at all how I remember force-push working.

That said, I usually use magit in emacs for git and understand the force options well, so I haven't actually looked at the standard push failure warning in years. Maybe I'm remembering wrong, or perhaps it's been improved in recent versions.

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

#418

Post by vlovich123 »

hintymad wrote: post #306
sasham wrote: post #297

Earlier quoted context omitted.

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…

Having an effective monorepo at scale will also require an entire infrastructure to solve all the problems that a poly-repo must solve and more. In particular, - Partial download, as a monorepo will quickly grow too large for a single person to download. This is trivial for poly-repo but requires dedicated system for monorepo. - Dependency management. With a decently sized monorepo, one can't compile everything and t…

It’s not fully open source yet (ie you can’t use it yourself I think) but Facebook’s EdenFS project solves the partial checkout problem.

The queries in Bazel/Buck to figure out the changed set of dependencies probably isn’t complicated and that’s why there’s no turnkey solution? You do need to adopt a build system with precise dependency tracking (afaik only Buck and Bazel support that) or the monorepo path isn’t going to be very successful.

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

#419

Post by vlovich123 »

weebull wrote: post #400
sasham wrote: post #297

Earlier quoted context omitted.

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.

Sorry no. CI and monorepos are at best tangentially related. Dependency tracking across repos is a PITA which inhibits code reuse - git sub modules suck as do whatever that alternative git submodule concept is called (subtree?).

Code repos like Cargo and NPM can help but even still it’s an annoying dance to update dependencies in multiple downstream projects. And if there’s a code change you need to make, it’s a 3-way orchestration of new api, update downstream dependencies, remove old api.

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

#420

Post by vlovich123 »

foofie wrote: post #397
jitl wrote: post #365

Earlier quoted context omitted.

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…

That’s a really slow review process. It also prevents reviewers from seeing the bigger picture of how step 1 manifests in step 2. In practice what I’ve seen you end up with both reviews simultaneously referencing each other in the description and once approved you merge 1 and update the pointer in 2 to point to the new merged commit if it changed.

That’s a lot of annoying and sometimes error prone manual bookkeeping that has nothing to do with the engineering work itself

Post reply on HN