Version Control for Everything • Hacker News Board

Re: Version Control for Everything

#51

Post by somethingsome » Fri, Aug 21, 2026, 6:34 PM UTC

ammar_az wrote: post #15

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…

Maybe what I'm saying is stupid or malinformed, but why not having the doc as a separate repo, and set it as a submodule to the repo where the code lives? Agent should be able to push code to the submodule independently from the code, and it should not be problematic for the main repository

Re: Version Control for Everything

#52

Post by TYPE_FASTER » Fri, Aug 21, 2026, 8:29 PM UTC

cfjgvjh wrote: 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

I guess it kinda depends on your use case. If you're versioning software artifact binaries and want to have support for rules for retention (keep n number of builds around), version numbering (you can only write a release artifact with a version number once), etc., using Git for text and Artifactory for artifact binaries has worked pretty well for me.

Re: Version Control for Everything

#53

Post by eru » Sat, Aug 22, 2026, 2:46 AM UTC

emmelaich wrote: post #33

eru wrote: post #21

Earlier quoted context omitted.

Funnily enough, git doesn't actually allow you to 'change' any history. It allows you to make new history, and the old history might get garbage collected eventually.

It does (let you change history), but in a tamper evident way.

It's two different ways to see the same thing.

Basically, almost everything is immutable in git, apart from tags and branches: these are mutable pointers to immutable commits.

Re: Version Control for Everything

#54

Post by ammar_az » Sat, Aug 22, 2026, 11:36 AM UTC

somethingsome wrote: post #51

ammar_az wrote: post #15

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…

Maybe what I'm saying is stupid or malinformed, but why not having the doc as a separate repo, and set it as a submodule to the repo where the code lives? Agent should be able to push code to the submodule independently from the code, and it should not be problematic for the main repository

I think this would a greatoption. Projects can start with two repos; one for code and one for docs. Then it would possible for code repo to add the docs one as submodule at anytime.

Actually I would suggest that to one of the projects that I'm currently involved in

Re: Version Control for Everything

#55

Post by catlifeonmars » Mon, Aug 24, 2026, 2:05 PM UTC

globular-toast wrote: post #36

catlifeonmars wrote: post #29

Earlier quoted context omitted.

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 just how plain git works anyway. Commits are just a tree of hashes which refer to the blobs in the objects store. Diffing is done on demand. If you can implement diff for binary files, then you've got git.

True. The main difference, like you pointed out, are the concept of a file tree and a commit tree which adds some structure along the time and space dimensions on top of the content-addressable blob storage.