Live data from Hacker News

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

news.ycombinator.com

231–240 of 440 posts

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

#231

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…

[deleted]

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

#232
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.

I'd say git is deceptive: "checkout" doesn't mean "delete my stuff" any more than checkout a book from the library means throw it in a wood chipper.

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

#233
post #218
post #16

I 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.

In part yes, e.g. lots of people like SourceTree. Some of the complexity is inherent though, e.g. local vs remote branches and the various conflicts & errors as a result. Git exists for 18 years, and yet the complexity problem wasn't solved yet. Other tools like SVN were never considered to be so hard to use / easy to screw up.

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

#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 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
post #116

>> 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…

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

#236
post #221

There 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.

Open sourcing code can require a lot of resources to do it right (manage the community, handle licensing etc). If you don't have customers asking for it and you don't need it for customer acquisition it might not make sense.

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

#237
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…

Learn your tools or one day you’ll lose a finger, or worse, your life. — high school shop class

Yet software is not a chainsaw and a huge amount of people never learn to use their software tools. Especially since they're 100x more complex than hardware tools and nobody has time to master everything.

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

#238

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.

rerere has worked pretty well for me when handling conflicts and it’s built into git.

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

#239
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…

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.

Ummm... A lot of people just endure using git. Go to the average enterprise software shop, the ones where people don't code for fun in their spare time, and ask around.

There are a lot more of those devs than unicorn and FAANG devs.

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

#240
post #152

Earlier 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…

Honestly I don’t understand why not more people use a GUI for git.

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.

Post reply on HN