Live data from Hacker News

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

news.ycombinator.com

331–340 of 440 posts

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

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

You can do most of this in git via custom diff-driver and smudge/clean filters.

For example git can already convert line-endings on the fly for windows. This is special-cased, but can just as well be implemented via smudge/clean.

Oh and git-lfs is done via smudge/clean too.

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

#332
post #131

Earlier quoted context omitted.

Yep, exactly! I remember these "happy" SVN days as well. It sucked, git was much better. Today you're almost never offline though, you even have wifi on airplanes. Git's datastructures are a masterpiece, for sure

> Today you're almost never offline though, you even have wifi on airplanes. The airplane wifi is good enough to look up an API, but it's not good enough to sync a code repo, especially one with large assets.

For assets no, definitely. At least until they get Starlinks :D I did commit into our code repo from an airplane though.

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

#333

Earlier quoted context omitted.

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

sigh So, in GameDev, art assets are as important to the final game as code. And is, just as important to be version controlled as code. And sure, you can split it up between many different repositories, and call it modular But you're just adding complexity, and not really solving the core problem which is that a single version of an art assets can possibly be > 1G, and be a poor format to be stored delta-encoded, so…

It's not rocket science to know that if you have a 1 TB git repo filled with massive binary files that all need to be version controlled, youre doing something VERY wrong or you are using the wrong tool.

Literally the very first result on google search says almost every major game studio on earth uses perforce due to this specific problem because perforce allows you to check out binaries on a file to file basis and mark them with a change list. This appears to be a solved problem with numerous solutions.

Theres also git-annex mentioned in the thread and a number of other options.

I love that you're saying I have a big ego, but you're doing exactly one of the things I'm suggesting in your studio. lol

This Diversion seems doomed if they're competing with git, but if they're competing with perforce, that's a different story. They're probably still doomed, but at least their product fit makes sense.

https://www.reddit.com/r/gamedev/comments/2xc5fx/whats_a_com...

https://git-annex.branchable.com/

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

#334

> We’re planning to release it as open source once the code base matures, If it's not open source, I'm not touching this. The one thing Git has over all these alternatives its that GitHub dies, Git is still around and is GPL. If you really want to be taken seriously, please make sure its open source with a copyleft license.

Point taken! Why copyleft though, and not MIT/Apache?

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

#335
post #99

Earlier quoted context omitted.

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 :)

OK so `git clone --filter=blob:none`, then. That downloads the tip and commit history, but no historic blobs. `git blame` then works by downloading missing blobs on demand, which doesn't sound too different to making an API call.

Which, yes, but now we're at the "instead of using Dropbox I would just rsync to my Linux server" stage of it being a product.

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

#336
post #168

Earlier quoted context omitted.

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

No, large companies using monorepos will have repos much bigger than Linux even without large binary assets. Apparently Linux has ~10 commits per hour. I probably do ~10 commits per week. So a team of ~150 mes produces commits at a fast rate than Linux. Very rough estimate but it takes less than you'd think.

Also if you vendor a few dependencies that quickly increases the size.

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

#337

Earlier quoted context omitted.

> With that, I don't think git has any feature that is unsafe by default. Well, you just mentioned `--force`. It is unsafe by default. Git has a couple of flags to make it safer (`--force-with-lease`, `--force-if-includes`) but those aren't the default.

The feature is 'git push'. --force is the opt-in to the unsafe behavior. It should not be used lightly.

You're missing the point. `--force` is the default of the force variants. The other `--force-but-something` arguments clearly modify that default. It's the wrong way round.

Obviously they've done it for backwards compatibility, but the fact that they haven't even added an option to make it the default is pretty lame.

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

#338

Earlier quoted context omitted.

> With that, I don't think git has any feature that is unsafe by default. Well, you just mentioned `--force`. It is unsafe by default. Git has a couple of flags to make it safer (`--force-with-lease`, `--force-if-includes`) but those aren't the default.

If you’ve ever had to remove private information from history before making the repos public (think domains, names, configuration, etc) you will appreciate the ability to rewrite history (and all the other things --force gives you)

I don't get your point. Nobody is saying don't use `--force`. Just that the default `--force` flag is the most dangerous variant.

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

#339
post #300

Earlier quoted context omitted.

> Monorepos are indeed causing problems with git, and this is one of the main arguments against them (see [1]). The article is a disappointing read. It spends a lot of time talking about monorepos and how they spell all sorts of trouble. Yet, the article makes zero mentions of submodules as a way to get the best of both worlds.

Submodules are great, but they're hardly an alternative to monorepos.

ive never seen positive feedback for submodules before

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

#340

> 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 Git sync feature allows one to import an existing git repo (currently GitHub is supported) into a new Diversion repo, and keep both in sync: every commit into Git is imported into Diversion and vice versa.

This allows a member of a team that works with Git to try Diversion, to keep backups, and to use GitHub Actions or other CI tools that work with git.

Post reply on HN