21–30 of 55 posts
Ah, we've got back to the "we should event source everything, and allow ourselves to change history and re-snapshot current state", idea gaining followers again. Well, yeah. But it's hard. Also, git is not the solution to this, it's just the screwdriver you have in your hand right now.
It allows you to make new history, and the old history might get garbage collected eventually.
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
Why not just fork git and make it better at binary files?
Earlier quoted context omitted.
Problem with dealing with binary files with git (or source control in general) is that you want to be able to see diffs, which is very dependent on the type of binary file you have. I think you can create git plugins to show diffs in different formats for certain file-types (or even open a 3rd party tool to let you visualize it), but it is a lot of work. Most productivity tools don't have anything of the sort. If you…
The problem is really starting g with a coders mindset that reducing a change to an explicit visual representation of a minimal delta is such a useful thing for everybody. It isn't. For example, for images, an A/B comparison is enough in a lot of cases. There are also no meaningful ways to "merge" changes for a lot of data outside source code, so the insistence that version control can't exist without merging is shor…
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…
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.
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…
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 to use P4V at least :-P but that's a different topic) because P4 a) can handle big files just fine and b) you don't really care about the history of the entire repository, but only about the part you're working on. For example personally i had my history tab display just the engine's code directory (and even then i rarely checked it since i don't really care what Joe working on the animation code did, my main interest was on the stuff i worked - and P4V showed me both if someone else is working on the same files i am and if my files have been modified, with easy GUI tools to see both diffs and the file's development history visually - the timeline feature is honestly great for that).
Perforce has some fundamental issues in how it works that creates problems, probably because of some deeply ingrained assumptions stemming from the 90s when it was first made that were never addressed, but it also has a lot of features (especially on the P4V GUI client) that makes working on a huge monolithic repository where everything goes in pretty much seamless.
I agree that LLMs introduce a lot of new issues. We’re going to be developing a whole new paradigm, for working with them, and we’re just at the very start.
Ah, we've got back to the "we should event source everything, and allow ourselves to change history and re-snapshot current state", idea gaining followers again. Well, yeah. But it's hard. Also, git is not the solution to this, it's just the screwdriver you have in your hand right now.
The revert safety net is what makes agentic coding tolerable. Without version control, every AI mistake becomes permanent, and that alone kills the workflow.
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
Ah, we've got back to the "we should event source everything, and allow ourselves to change history and re-snapshot current state", idea gaining followers again. Well, yeah. But it's hard. Also, git is not the solution to this, it's just the screwdriver you have in your hand right now.
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.