Disclaimer: I am designing a Git alternative too. Maybe "cloud native" will have a pull for game companies, but I am not so sure. I think a lot of studios would want to self-host. "Git compatible" is an interesting phrase; does Diversion use the same type of backing store? If so, I am not so sure it will handle large files as well as hoped. I had to solve this problem myself, and I did, but it required a different st…
Launch HN: Diversion (YC S22) – Cloud-Native Git Alternative
231–240 of 440 posts
Re: Launch HN: Diversion (YC S22) – Cloud-Native Git Alternative
#232Being 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.
Re: Launch HN: Diversion (YC S22) – Cloud-Native Git Alternative
#233I have not analyzed the full potentials and benefits of Diversion but I would not agree with the statements you made about the Git. I think you should not focus on Git in your pitch. >> it was built for a very different world in 2005 (slow networks, much smaller projects, no cloud) Slow network: why is this a negative thing? If something is designed for a slow network then it should perform well in a fast network. Mu…
The complexity people think they face with Git can often be overcome with a good UI and/or tutorials.
Re: Launch HN: Diversion (YC S22) – Cloud-Native Git Alternative
#234I 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 some agreed-upon shared AST target.
I know it might seem unhinged at first, but think about it: your (parseable) code is representation of the tree anyways (with some unrelated "whitespace fluff" around). If you follow strict formatting rules that you can express programmatically, you can recostruct that "fluff" from bare AST. If you can store all your violations against your style near the code, you can even sin and break it. If you store data about what you need to see differently from the shared AST - local renames of variables, for example - then you should be able to use your own naming convention, formatting and even source language, without bothering collaborators with tabs/spaces, hungarian notation or the fact that you prefer some different dialect or metalanguage.
Re: Launch HN: Diversion (YC S22) – Cloud-Native Git Alternative
#235>> most notably in games development, semiconductors and financial services are still using legacy tools like SVN and Perforce I think this should be your elevator pitch. Don't focus too much on "git complexity" as most people already know git so it just creates an argument. Scalability, in terms of numbers of users is somewhat hard to argue as well (Linux kernel has 1000s of contributors). However, it is completely…
> 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…
— high school shop class
Re: Launch HN: Diversion (YC S22) – Cloud-Native Git Alternative
#236There doesn't seem to be any justification offered on why it's not yet open source. Not that one is required, but it is suspicious that such a commitment isn't a priority, and that maybe there is a desire to keep closed-source as an option. Personally, I'd not want to check any assets into such a tool before it becomes open-source.
Re: Launch HN: Diversion (YC S22) – Cloud-Native Git Alternative
#237Earlier 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…
Learn your tools or one day you’ll lose a finger, or worse, your life. — high school shop class
Re: Launch HN: Diversion (YC S22) – Cloud-Native Git Alternative
#238The 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.
I’ve worked with hundreds of engineers in a single codebase. Never had any issues like you’re describing.
Re: Launch HN: Diversion (YC S22) – Cloud-Native Git Alternative
#239Earlier 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…
It is just a tough argument to make: the thing you have been using for your entire career and used almost everywhere is suddenly too complex.
There are a lot more of those devs than unicorn and FAANG devs.
Re: Launch HN: Diversion (YC S22) – Cloud-Native Git Alternative
#240Earlier quoted context omitted.
Even a force push doesn't destroy the reflog or runs the GC server-side. I wonder how you can accidentally loose data with Git. I've seen lot's of people not being able to find it, but really destroying it is hard.
I configured my github to only allow commits with an anonymised email address. Time passed and I used another machine on which I had already opened that repo before. I pulled my recent work successfully, wrote stuff and then committed and pushed. Github rejected my commit as I had the wrong email address. I then had to try and work out how I delete a commit but keep all my changes so I could commit it all again but w…
What you describe would be 1 Minute of work and maybe 10 clicks with a very low probability of shooting yourself in the foot in Tower.