10
What do you need from an EU Git host when your repo contains a lot of game assets? (europe.pub)
submitted 5 days ago by to c/gamedev@programming.dev
7 comments fedilink hide all child comments
 

Hey all, I’m Marijn, and I’m building Vault42, an EU-hosted Git service.

I would like to cater to the needs of game developers, and offer them an alternative to GitHub.

Git LFS add-ons are available on the paid plans, but I would like to hear from people who work with large binary assets every day, like textures, audio, models, builds, etc.

A few things I’m trying to understand:

  • How large is your LFS store, and how quickly does it grow?
  • Is storage the problem, or transfer (teammates cloning, CI pulling assets)?
  • Do you rely on file locking for binary files?
  • If you have thought about leaving GitHub, what stopped you?
  • Do you have any specific CI/CD needs I should be aware of?

What would it take for you to move your game projects to another Git host? Replies here or DMs are both welcome.

About 50 people are on the waitlist so far, and I’d like a few game developers on board to help me get LFS right.

Thanks!

(Waitlist, if you want to follow along: vault42.eu)

you are viewing a single comment's thread
view the rest of the comments
[–] 3 points 5 days ago (1 child)

Hey,

Can't join waitlist unfortunately, AAA is still Perforce heavy. We get to use Git for Backend work at least though 😁

For that use case, have worked across a few places, and ran into a few different edges, though none have anything to do with LFS unfortunately.

  • one org was on GitHub, used Jenkins for CI. We built micro services in multiple repositories, so being able to create repos on a pattern was really useful. We used Cookie cutter + Cruft to template and try to roll out the templates across all the repos when changes were needed, which worked sometimes. Being able to do that reliability in repo would be amazing, but static templates would be a good starting point.
  • another was on GitLab. They made heavy use of the organisation/project/subproject/repository kind of structuring, which worked really well except for integration with Go (I think there's a doc on GitLabs side talking about it now but it didn't exist back then). Used their CI tooling heavily, integrating renovate for dependency updates and driving iac through it as well (with terraform).
  • one smaller org was a monorepo with code in C# - there were a lot more binaries checked in here, though they changed less frequently. Also ran into the windows/Linux line ending fun on all the source code - smoothing that edge would be an awesomely useful feature for onboarding
  • most recent org use a monorepo for backend, are using CI and lots of self-hosted runners (for 8hr+ soak load tests), and have a lot of calls into CI and the codebase from Horde (newish unreal/epic ci system). They're just exploring GitOps stuff for CD - looking at ArgoCd and Kargo. They're very keen on a "promotion" style flow, if there's something you want to innovate on there 😊

Apologies I couldn't help much on the LFS side of things - the smaller org above did try to move into Git and did with one part of the studio for a while, but it made it harder for non-engineers to cross teams and studios because everyone else was P4.

  • permalink
  • fedilink
  • source
  • hideshow 1 child comment
    •
  • [–] [S] 1 point 1 day ago

    Woa, thanks for the detailed response, really appreciate it :)

    Interesting to hear about Perforce, I never even heard of that before. I wonder what makes it so suitable for AAA. Wondering also what an equivalent for indie devs could be, because Perforce sounds expensive and maybe overkill for smaller studios and solo devs?

    As to your points:

    Templates for setting up new repos: I think it would be doable to set up Cookiecutter + Cruft in CI, either on hosted runners or your own. For a dedicated instance it could be part of the infra package.

    Renovate I will also offer on the paid plans.

    For storing Terraform/OpenTofu state, Forgejo hasn’t implemented this on purpose; from what I can gather, the maintainers felt it doesn’t fit a code collaboration tool. The solution here would be to bring your own S3 bucket as the state backend, and run plan and apply from CI. For dedicated instances that could be part of the setup as well.

    On the nested org/group structure: Forgejo has a flatter structure than GitLab. Organisations own the repositories, and teams decide who can access which ones.

    As for your other ideas and suggestions, I have noted them down. This has been super valuable insight for me, thanks for letting me take a look under the hood!

  • permalink
  • fedilink
  • source
  • parent