Live data from Hacker News

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

news.ycombinator.com

281–290 of 440 posts

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

#281
post #268

Earlier quoted context omitted.

If you are using a chainsaw in a wood shop, you are probably doing something wrong. The saying “learn your tools” means to spend some time learning your options and what is available to you, learning the “gotchas” and why. Woodworking tools are rather complex with “gotchas” that will kill you in less than a hundred ms. Using Git isn’t much more complex than using a lathe (simpler even, as you can get by with no skill…

> Taking a weekend to learn the data structures, and how everything fits together is not a hard ask. Especially since you literally only have to do it once in your entire career. Like all simplifications, this is false. If all you do for years after is commit, push, merge, you'll forget. Especially since you'll need those brain cells to learn the new CPU/GPU architecture, the new JavaScript framework, the new corpora…

You don’t need to memorize it for life. Jeez man, don’t be so hard on yourself.

The point is, you know what is possible. You know what is impossible. 12 years later, something happens and you go … hmm, I used to know what is going on. I think I need to search for something about git-tree or something?

The point is, you know what to search for, a starting point. You don’t just reach for git cherry-pick, but realize you can use git rebase --onto to copy/paste an entire branch. You don’t worry about merge conflicts because you only have to do it once with rerere. You learn git reflog will remind you what branch you were working on this morning before you got pulled into some shenanigans in prod. You can set up automation with global hooks. There’s so much you can know to do less work and you only need to remember the parts that are valuable to you.

After learning git about 5 years ago stuff like ^ is all second nature to me, for nearly 10 years since switching from SVN. My first 5 years was just like you said. Commit, pull, commit, pull. I didn’t even know it could do anything else and I was worse for it.

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

#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 problem. Millions of people have been using github and gitlab. I'm curious about the percentage of users who feel that there is a scalability issue with their own repositories. Personally, I don't have any beef with git's scalability at all, even though the companies I worked for had anywhere between hundreds to tens of thousands of engineers. Maybe having a monorepo will lead to scalability problem? But monorepo is a debatable topic, to say the least.

> Diversion is built on top of distributed storage and databases, accessible via REST API, and runs on serverless cloud infrastructure. Every repository operation is an API call (commit, branch, merge etc.). The desktop client synchronizes all work in progress to the cloud in real time

Again, how does this have to do with me, a user? Why would I care about the underlying protocols when I simply use a CLI or a UI?

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

#283

Earlier quoted context omitted.

How niche is your use case? Despite all the questions I have about storing un-versioned large media files in Git instead of EC2 and your lack of good management about modularizing the code base and lack of build tooling....thats the use case I specifically stated in my post. The monstrosity that is Diversion could have great benefits for niche use cases like yours. i.e. large media file Version Control for teams who…

EC2 and a build script? Are you implying that the parents 1TB of assets are "un-versioned large media"? If so, I'm sorry you are being very dismissive about something you don't fully understand.

well then modularize your code better!

git can handle large repositories there's no reason you should have a one terabyte repository unless youre Google or something with the money to write your own VCS.

but if you want to pay for a nine developer team with a massive cloud infrastructure for something like version control.... go for it!!!

I'm going to check back a year from now and see if products still exists

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

#284
post #168

Earlier quoted context omitted.

How common are repos bigger than Linux? Linux also has the huge advantage of an ecosystem, tools and integrations. It is overkill for small projects and there are friendlier alternatives for those - but git wins because it is what everyone knows. Something aimed at the small number of large projects will suffer the same problem.

> How common are repos bigger than Linux? In terms of number of commits, Linux is probably bigger than most. In terms of storage size, almost any video game project will be significantly bigger. It's no secret that git is very bad at handling large binary files.

So this is very specifically for things like games with large binary assets?

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

#285

Little feedback on the "how is it different from Perforce" section of the web page. There have to be more advantages than "it's in the cloud" ...right? Also, for many this is potentially a huge hurdle / disadvantage. Who are you, and why should we trust you with our precious IP / code? (many game studios are on-prem very intentionally) Personally, I'm currently (being forced to) use Perforce and I've learned to toler…

Something of note, is that Perforce Helix does offer a Git interface, with Perforce Helix on the backend. It's something I'm looking to explore at my studio to better understand the tradeoffs there.

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

#286
There's a lot of remarks in this post that git isn't that bad, or that "losing data with git" is at best an exaggeration and at worst a lie. Other remarks include "People know how to use git", "--force tells you here be dragons", and plenty of git internals by way of explanation.

The posts remarks about git ring true to me. I, personally, would have lost work on many occasions if not for IntelliJ having its own "commit log" of every change I made since opening the IDE. I, personally, have had terrifying moments where I thought I'd lost large amounts of work, and spent the next hour fearfully searching google for how to unf*k myself. And I know several friends and colleagues who have had the same experience, and some who were unable to unf*k themselves and gave up: resigning themselves to just recreating the lost work. The fact that their lost work is probably still somewhere on their main repo to this day is cold comfort I'm sure. "It works for me" where "me" is an advanced level of nerd (myself included) is in the same territory as "It works on my machine".

This also seems to have really hit a nerve. There wasn't just one post saying "Meh, git is easy to use, you're an idiot" and that was enough. There was immediately a great many responses on the lines of "well, it's not that easy" or "well, I've lost work", and a whole back and forth has ensued. The fact there has been a borderline flame-war here tells you that git absolutely has room for improvement. Most of the remarks in defense of git feel like "Git Gud" [0], a term used to heckle newbies at video games, yet rather appropriate here. I don't want my version control system to be like Elden Ring: arbitrarily difficult with deliberately punishing pitfalls.

So, yeah, I'd love a better version control than git, and so would many others. I've had work saved from git by IntelliJ's internal commit log (where every edit is saved), so having that as a feature would be great. Being able to learn if someone decided to rename some class that I'm currently using heavily would have been helpful on many occasion (rare, but painful). Being able to pull someone else's work before the commit it, for review, very helpful. Support for large binary files without killing my local machine.

Good luck.

[0] https://knowyourmeme.com/memes/git-gud

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

#287

The world needs a git alternative. Anyone who has used mercurial at Google or Facebook knows the tooling could be much better. As soon as you have 2-3 people committing to the same repo daily, git falls apart fast. The biggest difficulties with git are merging and branch rebasing. If git could do rebases better, I would suspect software development teams to universally move about 20% faster.

Rebasing is extremely easy with git. Sounds like more of a skill problem then a git problem.

I think the issue comes about more when you have refactoring going on at the same time, and suddenly multiple feature branch maintainers need to figure out if they're going to merge in the main branch, rebase onto the main branch, if it makes sense to squash their changes first before attempting either path, etc. If they get only partway through either one, it's difficult work to pause and resume, so that integration work is fundamentally hard to collaborate on or even really review.

And never mind maintaining an ongoing integration of multiple unmerged feature branches— perhaps that's more of a "front end" issue for GitLab and Github to solve, but the whole business of patchsets and the like is very much unsolved, and that's painfully obvious when you see Debian storing their quilt patches inside of of a git repo, rather than being able to leverage git's native capabilities to achieve those effects: https://salsa.debian.org/debian/netplan.io/-/tree/debian/0.1...

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

#288
post #234

Out of curiosity, are there any VCSs that operate on AST instead of plaintext lines? (Or is something like this being developed or proven impossible?) I guess it should be possible to cooperate on shared codebase without need for every contributor to check in and out text files following exactly the same formatting. Or even naming convention. Or even same language, provided all collaborators can transpile to and from…

I was thinking about trying this out, but there are some reasons why I don't think it's feasible. Where are your comments stored? What happens when you need to run out in the middle of a fire and you don't have time to make your code compile-able? How do you commit "un-compile-able" changes? I think there are some really compelling reasons to try AST-checkin - all your loops can now be changed to functional, dialect…

Nodes in the AST for comments, block comments and "raw text I don't understand" seems like a way to go?

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

#289

Earlier quoted context omitted.

>> When Micorosoft adopted Git for Windows, they faced this problem and solved it. > On Windows. On Linux Git still doesn't scale well to very large repos. All of Microsoft's solutions for git scaling have been cross-platform. Even VFS had a FUSE driver if you wanted it, but VFS is no longer Microsoft's recommended solution either, having moved on to things like sparse "cone" checkouts and commit-graphs, almost all o…

`fsmonitor` is still only available for Mac and Windows. https://git-scm.com/docs/git-config#Documentation/git-config...

Fair enough, though there is a hook to provide your own on Linux: https://git-scm.com/docs/githooks#_fsmonitor_watchman

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

#290
post #69
post #51

Being deceptive about Git's shortcomings is going to raise eyebrows with anyone seriously evaluating your solution, which is already going to raise eyebrows because it's not free software. Most studios will try to avoid locking themselves into another expensive, annoying VCS that they have no control over. There's good attempts at FOSS p4 replacements now, you need to do better if you want to stand out.

> There's good attempts at FOSS p4 replacements now, you need to do better if you want to stand out. There are? Like what?

I've been attempting this but have paused the efforts due to what seems like lack of interest -- giving me an indication that the problem is not that big of a deal.[0][1]

If anyone is interested in my resuming them, let me know at contact at weedonandscott dot com

[0] https://www.reddit.com/r/vfx/comments/11s08ne/your_opinion_o...

[1] https://www.reddit.com/r/gamedev/comments/11s5haf/what_do_yo...

Post reply on HN