21–30 of 216 posts
My initial reaction is if this is not something than could be built on top of Git, rather than replacing it. Describe the data model - what is a "commit", what is a "branch" ..., if the same as git, then why not reuse.
I have always wanted a version control system that was basically Emacs/Vim/Neovim's undo-tree[0] but persistent and social. Why do I have to manually talk to git? You are a computer, track every modification I make while editing and let me decide (or help me decide) on what a checkpoint is. [0]: https://i.sstatic.net/4vbd9.png
Jujutsu might be what you’re looking for then.
It's absolutely great for keeping a bunch of exploratory changes alive, quick prototyping, etc. as I tend to do with basically every source I have on my machine. I don't have to think at all about the stuff I hate about git (babying the index, being careful to amend and etc. right the first time because undos are annoying, etc.)
Does not support LFS or submodules though.
Earlier quoted context omitted.
> And yes, no separate LFS system! Awesome. How does one decide which files should be stored externally, and manage that? And where is that decision stored?
I'm a little confused by this but I assume you're talking about marking files for LFS (.gitattributes)? For us, we chunk every file (even if it's a single chunk) so every file is stored in the same way -- it's just data to us. But let me know if I got your question wrong.
https://epicgames.github.io/lore/explanation/system-design/ if not
"Git is forever" Many things were forever until they suddenly died, but I think this is especially true for git. I'm not saying this as a git hater, quite to the contrary. I think git is great. I also think git is an ill-fit for the majority of modern commercial software projects and there will be a breaking point where companies realize that and move on.
What is git not suited for in modern development? I haven't found any reasons.
There's plenty of workarounds too, but that's what they are. Workarounds.
"Git is forever" Many things were forever until they suddenly died, but I think this is especially true for git. I'm not saying this as a git hater, quite to the contrary. I think git is great. I also think git is an ill-fit for the majority of modern commercial software projects and there will be a breaking point where companies realize that and move on.
What is git not suited for in modern development? I haven't found any reasons.
Earlier quoted context omitted.
What is git not suited for in modern development? I haven't found any reasons.
Git is great but if you really haven't found any reasons then you haven't looked at all. From large files to sub modules to hook permissions and file permissions... The list goes on and on about what where git falls short. There's plenty of workarounds too, but that's what they are. Workarounds.
What I want from a version system is to capture event in history not like changes as a files but as events that capture a process. If I split a file in two I still want to be able to see blame correctly for the author of the function, not one file as freshly created and the other with a bunch of deletes. I wish commits could be folded into larger commits so that you can still capture the individual changes but also n…
"I wish commits could be folded into larger commits so that you can still capture the individual changes but also not see them by default when looking at the history of a file." Fossil merges do this. More people need to use Fossil; it's got a ton of great ideas. "If I split a file in two I still want to be able to see blame correctly for the author of the function, not one file as freshly created and the other with…
There's a reason no one has done that, the VCS would have to have a semantic understanding of what it's tracking. I'm sure that's possible, but I think would see extremely limited success. Honestly, it may have even been done for proprietary languages and VCS systems that have since faded into obscurity.
I'd settle for searching the git history for a particular regex/string and then running a blame on that.
A few comments: * The core idea sounds interesting. Make it the first paragraph, not paragraph seven. * Spend more words describing what makes Oak different. * "I built a version control system in my free-time called Jam". You probably didn't name your free time. "I built a version control system, called Jam, in my free time."
"I built a version control system, in my free-time, called Jam" is fine.