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

91–100 of 440 posts

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

#91

Post by sasham »

jupp0r wrote: post #79

Having worked with SVN a decade ago and Perforce more recently: that part of the market is waiting to be disrupted. I'm a little unsure whether it was actual technical reasons (vs cultural) that kept git out of those use cases. Many devs were working with git locally and using git-svn or git-p4 to interact with the local repo. Best of luck!

Thanks!! Having talked to lots of game studios (and other companies with large repos/files) - many of them tried to switch to git because devs wanted to, and failed because of technical limitations.

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

#92

Post by fidotron »

As others have mentioned I believe you underestimate the security requirements (often physical) imposed on game studios. Running P4 (and using the often publisher mandated tape backups) is the least of your problems in such an environment.

If diversion were to succeed it would need a huge security team because it would represent far too tempting a target. Games stuff inspires a level of attack which normal businesses simply do not encounter.

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

#93

Post by CJefferson »

guax wrote: post #36
Rygian wrote: post #29

Earlier quoted context omitted.

> This is mostly a configuration issue. I guess this was done by a force push command. IFAIK, you can disable force push by configuration. If a feature can lead to actual unintended data loss, it should come disabled by default. Are there any other "unsafe by default" features in Git? What would be a sane general default that prevents unwanted data loss, and why is it the case?

--force always imply data loss. You're overriding the remote state. Do people use it in an unsafe manner because they don't understand git and there lies a problem that could be tackled? yes. With that, I don't think git has any feature that is unsafe by default.

My biggest problem with git is branch deletion — if you never do it you end up with far too many, but deleting a branch can’t be version controlled.

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

#94

Post by sasham »

yanis_t wrote: post #90

> a data scientist accidentally destroyed a month’s work of his team by using the wrong Git command (EDIT: we were eventually able to restore from a non-updated repo clone, after a few hours) This is actually reads like a benefit of using Git. It's really really hard to lost something completely in Git, because reflogs, because there are multiple people on your team each has the same copy of the repo, etc.

For sure, but that requires a lot of expertise and leaves the non-experts free to shoot themselves in the foot...

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

#95

Post by osigurdson »

>> 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 true that git does not natively handle large binary assets well. You can even quote Linus:

"I really don't know what to do about huge files. We suck at them, I know."

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

#96

Post by [deleted] »

spacecrafter3d wrote: post #83

This looks really cool! Well done! Definitely looking into this for my startup. Currently we use a mix of Git and Perforce, but Perforce is a pain to maintain and very difficult for the non-coder on our team to work with for art assets. When we started I looked at Plastic SCM (owned by Unity)—looks like it targets a similar use case to Diversion. I honestly can’t remember why I moved away from it—I think it was the l…

[deleted]

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

#97

Post by sasham »

spacecrafter3d wrote: post #83

This looks really cool! Well done! Definitely looking into this for my startup. Currently we use a mix of Git and Perforce, but Perforce is a pain to maintain and very difficult for the non-coder on our team to work with for art assets. When we started I looked at Plastic SCM (owned by Unity)—looks like it targets a similar use case to Diversion. I honestly can’t remember why I moved away from it—I think it was the l…

Thanks!! What do you work on?

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

#98

Post by sasham »

buremba wrote: post #87

Rather than "Better GIT", it would make sense to position it as "better GIT backend" in my opinion. I get the desire to replace GIT bash but it might be harder to convince developers, who is your target audience.

Yes you might be 100% right. We were debating this a lot in the beginning. In the end we decided to build a separate VCS with Git sync, and simpler UI (for now at least - might change, depends on user feedback)

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

#99

Post by egaldv »

darrenf wrote: post #88
egaldv wrote: post #71

Earlier quoted context omitted.

The vast majority of version control system uses are not distributed, even if the system itself is (GitHub and BitBucket were born to essentially make Git centralized). An example use case is game studios having repos with very large histories (hundreds of GiBs and more) where the tip is significantly smaller. Having the entire repo history on your local machine might be infeasible, and usually unnecessary. Being abl…

> An example use case is game studios having repos with very large histories (hundreds of GiBs and more) where the tip is significantly smaller. Having the entire repo history on your local machine might be infeasible, and usually unnecessary. Being able to get just the tip and get the rest via API calls solves this. "Being able to get just the tip" is `git clone --depth 1`, isn't it?

And then you lose functionality, for example `git blame` depends on the history being available locally. If you want a working repository with all the source control features you need a regular clone. That's where "being able to get the rest via API calls..." kicks in :)

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

#100

Post by 4star3star »

vintagedave wrote: post #40

> I often wondered why Git is so difficult to learn, compared to other tools. Yes! This is something many people wonder -- other than those who love git :) I used to love Mercurial and I still mourn its mostly-loss. So I welcome a new DVCS system that is friendlier than git. > Diversion’s code is managed on Diversion! This is a good sign. > can synchronize with existing Git repositories (each new commit in Diversion…

The difficulty of git is that it can do so much in so many different ways. What's actually needed is something like a linter for git workflow, where an org can enforce an opinionated subset of git's capabilities in a prescribed order of operations.
Post reply on HN