271–280 of 440 posts
Ok, I'll bite. Looks interesting. My first thought, as a gamedev who has been in charge of selecting VCS at multiple studios. 1TB is not a lot, and I would really appreciate clear public pricing terms on data before committing to a VCS. Esp at the smaller indie scale.
Earlier quoted context omitted.
And the tool made a screwup that hard not only possible, but very difficult for the victims to recover from. Doesn't say a lot for git's usability.
A couple of thoughts about this: One is that the possibility of overwriting history / etc is a really powerful and useful feature, but one that should only be used with some consideration, hence being gated behind the scary '--force'. The fact that git provides one the ability to discard and overwrite commits for a ref shouldn't be an endorsement of doing so freely. I'm glad git has this capability though and any "gi…
Though I'll say that "--force" isn't necessarily a "scary-sounding" option name unless you're used to Unix CLI naming conventions.
Further, the warnings git gives you about this are virtually inscrutable if you don't already understand what's happening.
A good interface to "blowing away history" would give you a brief summary of what will actually be gone, e.g.:
"If you go ahead with this overwrite, the following changes will be completely removed from the repo:
a3bf45: Fix bug in arg parsing 22ec04: Add data from 2024-01-17 scraper run ...
Are you SURE you want to completely destroy those commits? (Y/n)"
and if user says "Y", output should log all removed commits and also say:
"These commits can still be recovered until . If you realize you want these back before then, run the following:
"
Generally, I think it's a mistake to put UI improvements in a secondary tool.
If there are issues that need fixing, get those changes in the canonical project, because layered patches on top will always be short of maintainers and behind the main project.
Ok, I'll bite. Looks interesting. My first thought, as a gamedev who has been in charge of selecting VCS at multiple studios. 1TB is not a lot, and I would really appreciate clear public pricing terms on data before committing to a VCS. Esp at the smaller indie scale.
Continuing: > Yes! It can integrate with any CI tool via Git compatibility, or using the API. Talk to us for more details. You really need to provide a comprehensive cli targeted to CI/Build. Git really is really going to be a bottleneck for games, and most teams aren't going to want to figure out the hassle of manually figuring out differential updates and multi-part downloads via REST Secondly, I watched your video…
Thanks for the feedback reg CI - I'd love to hear your specific needs, as we're working on this right now.
As a game dev I find the pitch unexciting. > git is bad we're better Honestly, a modern git lfs workflow is really smooth. I think it handles binaries fine. Show me cumbersome git feature and why this works better. You can't just tell me tools I use every day are unusable. I think the main pain of git is if you want to put everything in a single repo. Big isn't a problem, getting just what a I need (checking out a si…
Git LFS is a giant hack ontop of Git. Most game devs I know moved away from it over time (back to Perforce or SVN). It might seem okay at first - but deep into a project you'll want to rearrange/rename folders and keep history logs, and discover that Git LFS doesn't actually work like normal Git and your file history wasn't kept. Only once you start dealing with issues will you find all the weird hacks Git LFS does o…
Day to day I think its the industry tooling and the partial checkouts that have people pick P4, not esoteric problems you face years down the line.
Earlier quoted context omitted.
The pitch simply wasn’t true. Data was not destroyed and was restored hours later.
It's a pitch. The story has obviously been embellished and polished and condensed, ready public consumption. Being pedantic against it is not productive.
Ok, I'll bite. Looks interesting. My first thought, as a gamedev who has been in charge of selecting VCS at multiple studios. 1TB is not a lot, and I would really appreciate clear public pricing terms on data before committing to a VCS. Esp at the smaller indie scale.
Hi, sure thing! You can get extra storage at the same price as the Free tier (we'll make it clearer on the website).
Earlier quoted context omitted.
Continuing: > Yes! It can integrate with any CI tool via Git compatibility, or using the API. Talk to us for more details. You really need to provide a comprehensive cli targeted to CI/Build. Git really is really going to be a bottleneck for games, and most teams aren't going to want to figure out the hassle of manually figuring out differential updates and multi-part downloads via REST Secondly, I watched your video…
Windows is supported, as is Mac and Linux - should mention that, you're right. Most of our users use Windows, so it's definitely 1st priority. Thanks for the feedback reg CI - I'd love to hear your specific needs, as we're working on this right now.
going after git takes COURAGE, so I'll give you that lol
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…
> 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. Designing for resource-constrained systems usually means you're making tradeoffs. If the resource constraint is removed, you're no longer getting the benefit of that tradeoff but are paying the costs. For example, TCP was designed for slow and unreliable networks. When networks got…
Earlier quoted context omitted.
The Windows Git repository is only 300GB, that's basically childs' play when people are talking about "large repo scalability". Average game developer projects will be multiple terabytes per branch, with a very high number of extremely large files, and very large histories on top of it. Git actually still does handle large files very poorly, not only extremely large repos in aggregate. The problem with large Git repo…
This includes assets right or some kind of prebuilt data in custom formats? Otherwise it would be hard to have this much data in source files.
But honestly, you can ignore that, because Git doesn't even handle small amounts of binary files very well. Ignore multi-gigabyte textures and meshes; just the data model doesn't really handle binary files well because e.g. packfile deltas are often useless for binaries, meaning you are practically storing an individual copy of every version of a binary file you ever commit. That 10MB PDF is 10MB you can never get rid of. You can throw a directory of PDFs and PSDs at Git and it will begin slowing down as clones get longer, working set repos get bigger, et cetera.
The 300GB size of the Windows repository is mostly a red herring, is my point. Compared to most code-only FOSS repos that are small, it's crazy large. That kind of thing is vastly over-represented here, though. Binary files deserve good version control too, at the end of the day.