Live data from Hacker News

Version Control for Everything

tyoverby.com

41–50 of 55 posts

Re: Version Control for Everything

#41

Does anybody have experience storing issues/reviews in git? I know gerrit does this and keeps track of `change-id` to support rebase etc, but I think that requires a gerrit server to run. Would also be nice if GitHub issues/reviews were in sync so reviews are accessible during a GitHub outage.

Beagle indexes all the tickets within reach and shows them in one Excel-like view with buttons to manage their worktrees https://replicated.live/blog/click

There is a port for plain git repos named Bee. That one is earlier-stage, but works https://github.com/gritzko/bee

Re: Version Control for Everything

#44
This is why I’m convinced we’ll see a lot more “plaintext-first” apps going forward.

As agents take over more of our workload, it becomes increasingly important to store the data in a dumb and simple format that’s easy to diff and verify.

I talked about some of this at LocalFirstConf: https://youtu.be/2ZEBH5Clrnc

Re: Version Control for Everything

#45
post #22

Earlier quoted context omitted.

Why not just fork git and make it better at binary files?

You don't even need to fork it: git has something like a plugin system for exactly this use-cases. (I'm not exactly sure what their terminology is. But they thought about this use-case before.)

yes they are called git-merge drivers. https://git-scm.com/docs/gitattributes

I mentioned it before, see the following comment https://news.ycombinator.com/item?id=47749916

You can also use a custom difftool or mergetool that understand your formats. For example Beyond Compare https://www.scootersoftware.com/kb/moreformats

Re: Version Control for Everything

#46

The approach of having everything next to the code seems good in theory but it's just a nightmare in practice for big projects. Imagine your git history filled with commits from project managers where every little change in requirements and docs has its own commit. We've tried that and ended up having to rebase our branches multiple times a day while we lost the overview of code changes completely. The main issue tha…

The issue you describe seems to be related to the tools you're using and how you use them, not to the core idea itself. I've worked in several gamedev companies where everything was in a Perforce repository. In fact in one company EVERYTHING was in it, not just code and game data, but also documents, concept art, plans, everything. If it wasn't in P4, it didn't exist. Yet nobody thought it was a pain (after learning…

Sure, it would be better if you get the right tools for it and teach people how to use it. At the end Google was able to get all of their source code in one mono git repository and it worked for them but they invest really heavily in their unique tooling.

However, I still think it would be much simpler to extend the tooling for current project management platform to give AI agents the text-based user interface that they needed. This would be much simpler task than developing the tooling for huge repo to include all the chaos of humans communications alongside the code itself.

Re: Version Control for Everything

#47

The approach of having everything next to the code seems good in theory but it's just a nightmare in practice for big projects. Imagine your git history filled with commits from project managers where every little change in requirements and docs has its own commit. We've tried that and ended up having to rebase our branches multiple times a day while we lost the overview of code changes completely. The main issue tha…

“ every little change in requirements and docs has its own commit” I think this would be a great thing to have and know who changed what and when. It seems it’s more of a problem of the tools being able to help the user see only what he needs to see in a certain context.

It's a great thing if those changes live in their own repo and not mixed with changes to the code itself. Actually Jira has been doing that for a while now by offering the history view with a timeline for each change, also GitHub shows edit version for files as well.

The main role for projects management is handle the chaotic way of humans communication across different organization without developer being involved in that messy cycle. But having everything in the same repo will remove this decoupling and will let developers get involved in that chaos as it's part of the repo history.

Re: Version Control for Everything

#48
post #2

I really really want to do version control for everything, but most of my data is binary so it really doesn't agree with git; I tried using LFS as well but it didn't work for my specific workflow. Hopefully something less text oriented comes along in the future. Lore looked interesting for this purpose. https://github.com/EpicGames/lore

Hash the files and commit the hashes. Store the large files somewhere convenient, keyed by the hash. Voila, you’ve invented an LFS.

That's exactly what git-annex does: https://git-annex.branchable.com/

LFS is kinda close, but you don't store the files "somewhere convenient": you need support on every git remote to handle the files.

Re: Version Control for Everything

#49

Earlier quoted context omitted.

There are a lot of indie game devs and small studios that don't use any kind of formal system for this. Maybe they'll copy and paste the root folder once in a while. \Game - Copy (2) is technically version control, in a sense.

I would hope they have ways to track those assets. They may be worth tens of millions of dollars.

You would hope. I know of one case of an indie dev of an extremely successful, multimillion dollar franchise who did in fact lose everything related to the original game that made them successful, something which probably has cost them millions of dollars because they were unable to port it despite demand, and they've spent over a year recreating it from scratch.
Post reply on HN