Twenty years is nothing
deprogrammaticaipsum.com
deprogrammaticaipsum.com
So, at a customer site (while I was doing consulting for them), I couldn't stand it anymore (I had been using CVS myself since 1997). So I installed SVN to work on their project and showed it to the team. I was called an "irresponsible engineer"... "Modifying files without locking is a crazy! You don't do that on real engineering teams!"
The open-source world was at least 10 years ahead.
I'm not sure it is the win you're suggesting. I had brief stints with CVS and TBH it really sucked.
Luckily when I started coding seriously (which coincided with my first job), SVN just reached 1.0 and it was OK. This was 2004 already.
IMHO, the whole situation was fixed only after Linus decided he had enough of the crap and wrote his own.
What had you used that was better? CVS seemed like quite a step forward compared to RCS and the other available options.
Especially when compared with the options we have now, I think it's slightly misleading to say OSS solutions were in any real way better back then...
All I wanted to stress is that the "lock-before-you-can-touch" approach was the norm in the enterprise world at the time. IMHO, this fact alone made SVN (even CVS) better than all the commercial products which I used at the time.
When some of the "enterprise" world started adopting SVN and commercial products started relaxing the locking mandate, the open-source world was already embarked on the decentralized model (git, darcs, arch, mercurial, etc).
But, yeah, ClearCase sucked pretty hard and was frustratingly slow. Also, too easy to miss adding files to source control and really annoying interface to _find_ view-private files. 0/10, would not use again unless I had a gun to my head.
Now it's different, we think our new tools are good, and we really mean it. But it's different.
...a lot of companies didn't use any form of source control at all. :)
Just look at all the craziness about being able to manage software dependencies by publishing different microservices versions, or all the emphasis on software testing without any other kind of correctness verification getting the spotlight.
Oh, and those are the advanced companies out there. Most of them aren't even there yet.
Nobody uninstalls packages from a Docker container…
With immutable designs, we’re just reinstalling the whole OS on each update…just a bit more efficiently thanks to cheap storage.
Back in the primordial olden days, people used to patch binaries. These days, we just compile them from scratch, when we want to make a change.
So it's not too surprising that people apply the same approach to the whole OS installation.
Mutation is hard to get right!
QA was one guy doing manual testing with a checklist.
In all the configurations I'm familiar with, one can unlock a file for modification but the only effect it has on others, is that they will see that you are modifying it in one of your workspaces.
Locking had some nice side effects. The devs talked to each other. Things where someone was getting in the way all the time showed where the code needed to be abstracted better. In practice it was not that big of a deal (all in 1995).
What was really different from today though is that most developers did NOT run the application locally or in an individual environment. They all worked together in a common dev environment. It was either too difficult or impossible to run copies of the application locally. So that is why file locking was used. You had an entire team of developers simultaneously working on the same set of files.
You could also 'break the lock' locally then fix it up later (though this was discouraged). It also kind of forced you to make sure what you checked in built. As you would have 5 other devs coming over to ask why you broke the build. It was a manual process. Most of that sort of thing is handled by CI/CD type systems now. You can break the build on your branch. But no merging up of that junk...
We used a rudimentary CI/CD to enforce 'always builds and runs'. Someone wrote a bit of script that would check it out at 5PM and kick the build on a 'blessed' machine. If that failed the people who checked it in were on point to fix it the next morning.
It was not better or worse. It was just different and more manual. Manual though means steps get forgotten or skipped.
This flies in the face of my personal experience (first 7 years in industry was before Git adoption), and also in the face of what most developers at the time said.
I mean, just look at Joel Spolsky, one of the most popular developer-bloggers, who also founded StackOverflow, Trello and other things. IIRC, he wrote a blog post calling the invention of DVCSs the most important innovation of the last decade of innovations, then he put his money where his mouth is by creating a new product specifically built around the idea of DVCSs. (Though he made a "bad bet" by focusing on Mercurial instead of git, IIRC.)
I was tasked with 'finishing up' someone else's work who was away on vacation. All his code was in sourcesafe... locked to just him. And he was away for another 9 days with no cell phone or email (not really a big thing in 1999) and... I was immediately getting pestering emails from the PM. "When is this getting finished? Ben said it was nearly done, just needed a few more bits.". There was pretty much nothing I could do. VSS was something he'd set up on a server that only he had a password to, and... no one had thought to have him to coordinate with anyone before he left on vacation for 2 weeks.
That was one of the first times I felt "everyone else just thinks we're interchangeable cogs". Possibly the first time. If one of the PMs took vacation, or one of the accounting folks, there was some defined handoff process "to keep things running smoothly". No one seemed to give a toss about "devs" in that case.
sure do wish someone had checked those boxes for him!
sometimes it's still a surprise to me that I decided this is the career i still wanted to pursue after that experience but i haven't been shouted at like that since then.
I partially agree. But: one of the really nice things about distributed version control systems like git is that the guys running the servers can't make rules about what you are doing locally.
We were forced to migrate to SVN which I remember as being a pain compared to VSS.
The worst was our GIT migration. At the time it was not an easy Integration with visual studio. The process of migrating history was a challenge. We lost control of the process - suddenly GIT and corporate defined the process which for a small team was overkill and burdensome. The builds became laborious and time consuming.
This was years ago. I'm sure they've worked all that out now.
It's basically IT but for industrial operations instead of commercial.
https://www.cisco.com/c/en/us/solutions/internet-of-things/w...
Fast forward to 2008 and I am working on a project where we had an older person working on the project that would do this, use a scheduler to create a zip version. The younger guys I worked with said it was a crazy system and didn't understand why someone would do that. I told him it was an advanced practice just 10 years ago. Basically, people did a lot of stuff that would seem crazy now given the tools we have now.
This is a problem that can affect everyone, especially those working in more isolated areas. You come out with a great workflow in year X that's 5 years ahead of the industry, and it works, so you never progress.
Meanwhile the industry catches up, solving the problem another way, but you never learn because it's a step backwards, until it isn't, and then it's a massive learning curve.
You have to actively keep up with what the industry is doing and be willing to adopt the new ways of working even when they are in some ways a step backwards.
In any case, because of when they built that Continuous Integration system, it was all jerry-rigged on top of CVS. Problem is, they were still using that system for Slang 15 years later.
Sure they would. They believe anything. I made up some nonsense one day that bytes weren't always 8 bits and they believed that shit.
You reminded me of locking the centralized repo, I completely forgot about the headaches that caused! I'm now recalling how painful source safe was. I wonder if trauma caused me to forget.
Eventually everything migrated to SVN as part of the Linux migration, including windows desktop revision control. I was so used to the SVN/CVS patterns that I strongly resisted git later on after I'd left. I'd say it took me a good two years of grumbling before I finally opened my mind to git, and in hindsight it's brilliant. The biggest thing that I had trouble letting go of was having a monotonically increasing version number of the repo. That felt ... safe. I mean, now you just have to be liberal with tags.
I agree with the OP, git couldn't work 20 years ago on desktops because drive sizes were too small. Sure it could work on distributed computing, but AFS drives were slow, and NFS quotas were teensy. Git only worked because drive sizes exploded.
"Hey, Alex. I saw you've head BasePage.aspx locked since last month. Mind if I work on it for a bit?"
"I still need it."
"Any idea when you'll be done with it?"
"No."
This is what the waterfall model was made for.
In 2018
Why is it that every time something is written in Rust, it needs to be mentioned, just as that the language of choice would make it magically much better?
Version control is just a lot of bookkeeping so I doubt possible added performance (outside some well defined algorithms) can matter much.
Mercurial, written in Python, definitely experienced performance problems. Hilariously, the first search result I found when searching for "mercurial performance python" is https://wiki.mercurial-scm.org/OxidationPlan, which discusses reimplementing parts of Mercurial in — you guessed it — Rust.
Some days are just like that. Your synapses trigger on something because of historical reasons.
When you read a product description written by someone who hopes to draw positive attention to the product, it'll usually draw attention to its most important and distinctive features first.
For example, if you look up Stripe, you'll get "Stripe | Financial Infrastructure for the Internet - Stripe powers online and in-person payment processing and financial solutions for businesses of all sizes."
If you look up Uber you'll get "Get a ride in minutes. Or become a driver and earn money on your schedule." Clang? "The Clang project provides a language front-end and tooling infrastructure for languages in the C language family". Ubuntu? "Ubuntu is the modern, open source operating system on Linux for the enterprise server, desktop, cloud, and IoT."
When the place you usually see the product's best feature says "written in rust" it sounds like they're damning it with faint praise.
Of course, not everyone follows the 'best feature first' pattern. For example, when asked about Stripe the first thing Wikipedia tells you is that it's dual-headquartered in South San Francisco, California, United States and Dublin, Ireland.
There are other things related to the community/zealots/Mozilla/Rust foundation, but I'm not sure this is the proper place.
Edit: Git zealots are worse than Rust zealots, I attribute this to Git being "harder to learn" (i.e. never really does what people think it does) than Rust.
And, in some domains (version control is one of them; type checkers/linters/bundlers/compilers are another), it has proven to be extremely important.
Most of the times, privacy is not hard, you just have to not do stuff (tracking, data collection, etc...), and maybe use some crypto library. But before telling me what you don't do, what do you do? For example, when I see a search engine claiming privacy, I think "yet another Bing proxy", now, what do your search engine have over the other Bing proxies? Better results? Performance? A specific niche? Better UI? That's what I want to know.
1. Unless you abuse Rust horribly, it is both memory-safe and fast (which to me implies a degree of quality, unlike Python which makes me more... apprehensive in using tools written in it)
2. Rust is still not a major language but has an enthusiastic community. Rustaceans like the spread the word!
Yes. I have that too; mostly due to the very low quality of code ‘hacked’ in the language. It is the (not so) new BASIC and everyone and their sister are launching things in it that should be considered ‘weekend side hacks’ at most, but are announced as the next best thing.
4. The resulting binary will be a static self-contained compiled binary. This means a) no cluttering up your environment with dependencies b) fast start-up time
If it weren't for Rust, I'd use Go. But Rust's development tools are incredible with rust-analyzer, clippy, etc.
Also 5) it will keep working over time.
I know that if it's in Javascript, it will take a while to make it run at all; in Ruby I've spent too long reading your site, it's already incompatible; in Python it will break in a couple of years; and in PHP it will keep doing what it promises, but I'll have to work again and again to keep it only doing what it promises.
The fact that you don't mention computational complexity as the primary concern here tells me that there is something wrong with programming as of 2024. And not necessarily with Rust per se but maybe all the other languages.
Why should humans bother with anything else than choosing the right algorithm for the task? And possibly not even that. It should be "combine X with Y such that i get Z"
Rhetorical question. I know I open up for many counter arguments, so please choose wisely to keep the discussion alive.
And maybe it is just as simple that Rust is the answer to that question?
There's also the fact that Rust tends to draw those who are already proficient with computational knowledge. Whereas the typical Python programmer is just a poor dud that never had any formal education in accessing computer resources.
But what I want to add to my last point: Most performance pitfalls I have seen are not due to choosing wrong algorithms, but bad implementations driven by messy implementation and low maintainability. Python and JS are absolutely among the worst of the bunch and weak dynamic typing is a terrible burden to maintain and scale.
Mind you, it depends on which domain we are talking about. If you are working close to the metal and you are using something like PyTorch, your performance is indeed determined by choosing the right algorithms and language overhead is less significant in comparison. But most software is just moving things around in memory and do a little networking.
But as a professional programmer for 25 years now, I'd say the fraction of our job that boils down to finding, designing, or implementing the right algorithm is sadly tiny. It's all the messy details that end up soaking our time and attention. One way to increase the amount that algorithms matter is to work at greater scale, which is basically why I moved from "programming at some corporation that does something else" to Silicon Valley technology companies.
The other important detail is that different languages allow for very different kinds of refactoring. I've found the Oxide and Friends podcast to be possibly the most powerful vote of confidence in Rust that I've ever seen in this regard. In their most recent episode -- https://oxide.computer/podcasts/oxide-and-friends/1734108 -- they discuss how Rust allowed them to make sweeping and rapid structural changes to their storage code that they wished they could have been able to do in the underlying layer -- ZFS. (This from folks who helped create ZFS or were at least adjacent.)
If your language allows you to make sweeping refactors safely, it enables you to mutate your code towards better algorithms for the task.
Also, it can give you more time to focus on the algorithms. If I, a novice C++ programmer, allowed to actually use C++ in anger, I'd spend all my time trying to figure out memory safety and ownership problems, not focus on the algorithms. I'm simply not willing to put in the multiple years of hard work it would take to be able to program C++ safely. But I'd be willing to let myself, a novice Rust programmer, use Rust. It might not be pretty, and the borrow checker and I might come to blows, but it wouldn't be dangerous.
(fwiw, I'm really a Go programmer. But I've lurked many programming languages and their communities during their early phases (Go, Rust, Zig, Roc, Perl6), and it's hard to argue that Rust is _really_ good at certain things.)
It took a little bit of work to get that down to actual fast code, for example I had to write my own key-value store, which wasn't a particularly pleasant experience, and I don't think any existing programming language could have helped, it would have required a full linear logic type system. But at least now that thing (Sanakirja) exists, is more generic, and modular than any storage library I know (I've used it to implement ropes, r trees, radix trees…), and its key-value store is faster than the fastest C equivalent (LMDB).
Could we do the same in Haskell or OCaml? As much as I like these two languages, I don't think I could have written Sanakirja in a garbage-collected language, mostly because Sanakirja is generic in its underlying storage layer: it could be mmap, a compressed file, an entire block device in Unix, an io_uring buffer ring, or something else. And the notion of ownership of the objects in the dictionary is absolutely crucial: Sanakirja allows you to fork a key-value store efficiently, so one question is, what should happen when your code drops a reference to an object from the kv store? what if you're deleting the last fork of a table containing that object? are these two the same thing? Having to explain these to a GC would have been hard I think.
I wouldn't have done it in C/C++ either, because it would have taken forever to debug (it already did take a long time), and even C++-style polymorphism (templates) isn't enough for the use of Sanakirja we have in Pijul.
remember the "poop" paper about mmap for databases, right? Well, guess what: having a generic key-value store implementation allowed me to benchmark their claims, and actually compare congestion, throughput, speed between mmap and io_uring. Conclusion: mmap rocks, actually.
Did you write up the mmap results as a paper? Sounds like it would be quite useful. (Is this the paper you're referring to? https://db.cs.cmu.edu/papers/2022/cidr2022-p13-crotty.pdf)
From the linked "Mozilla moving FireFox to Git" blog post:
> "a Mercurial and a Git mirror of the Firefox source repository [...] I think I just wanted the speed that Mercurial was not providing. Not that Mercurial was that slow, but the difference between a couple seconds and a couple hundred milliseconds was a significant enough difference in user experience for me to prefer Git"
> "as time was passing and the size and depth of the Mercurial repository was growing, these tools were showing their limits and were too slow for my taste, especially for the initial clone."
> "My user experience with Mercurial had reached a level of dissatisfaction that was enough for me to decide to take that script from a couple years prior and make it work for incremental updates. [...] You could get a full clone of mozilla-central in less than half an hour, when at the time, other similar tools would take more than 10 hours (needless to say, it's even worse now)."
> "the repository growth didn't take a break, and the Try repository was becoming an increasing pain, with push times quite often exceeding 10 minutes."
And in the comments:
> "There is at least one currently very active (but private) repository that is (much) larger than Mozilla’s at Jane Street. We (Octobus) are working with them to improve a lot of aspects of Mercurial’s speed."
p.s., i know it's good stuff. but still.
Correspondingly:
Why is it that every time it is mentioned that something is written in Rust, someone has to ask why it is mentioned?
Two answers for your question:
* Because Rust has some special qualities, and evangelism is real.
* Because we, as the developer audience, afford some additional consideration to choices made by the developers of the open source tools we use. Sometimes because we contemplate making changes, or at least reading the code to understand behaviour better.
Nothing magical in Rust, at the time it was the only language that worked seamlessly on Windows and Linux, and made it easy to manipulate on-disk datastructures, which is what makes Pijul fast. The new take on version control that Pijul brings can be roughly described as seeing "files with conflicts" as a CRDT. It was therefore crucial to be able to manipulate complicated datastructure without loading anything, and Rust seemed to let us do that without having to do C++ and spend our time debugging allocation issues in our tricky algorithms, while never being really confident that we were done.
The library I wrote for this, called Sanakirja, is actually faster than the fastest C equivalent, but this isn't because "Rust is magical", far from it.
Is there an online tutorial where you are given small tasks to do in Pijul?
I'm curious, but not willing to read in dept documentation just yet :)
As a user experimenting with tools, ones written in Rust have justified these prejudices. They simply tend to be better.
It's an effective advertisement. I'm a little confused why there's always someone who brings it up. It's not like programming language makes absolutely no difference. If it's written in C or C++ and it's relatively young, I'll expect it to be unstable and to have a clunky and unpleasant interface. If it's in Go, I'll expect much better in stability, but with a funky CLI. If it's Python, I know it uses argparse, so at least the CLI will be consistent. If it's Rust, I expect it to be fast, to have very few or no panics, to have no memory issues, to have zero null pointer problems, and to use clap for a very consistent, predictable, and good looking CLI.
The language has built a good reputation; I'm shocked that commenters on HN have somehow avoided picking up on that and are perpetually surprised that it has a real audience.
One of the reasons is that's in C.
Nothing. I just don't see it, text based software development is at its best currently. Only thing nowadays is AI that helps you to figure out or speed up creating code in text. AI models are all about text based languages, all the low code or image based programming is not good base for AI models - generating images is obviously not going to generate block diagrams for working software as good as text generation.
So text manipulation is going to stay, we might have additional tools like AI to quicker create/process text and GIT is already best model for keeping history of textual changes and yes we want that history, because we still need to be in control of complex systems that are described by textual representation in whatever language is used.
People who find reading and writing tiring and nuisance that should go away are not going to change it. Even if neuralink happens to be everywhere I don't think it has a way to write information back to the brain so I think we are stuck with reading for quite some time. While images are much more information dense, text can be very precise and one cannot describe complex system with images/feelings only.
Git doesn't even keep history of changes, just snapshots before and after the changes. A very common problem is viewing history of a single file as it gets modified and renamed - this information just isn't stored. It's common for tools to show file history incorrectly - i.e. a previous version is removed and the new one (with small changes) magically appears.
E.g. see https://portal.perforce.com/s/article/3447 for Perforce.
Just the fact that people keep using placeholder files should be enough to convince anybody. But if you want to use git for software development, well, almost all development conventions mandate directory intentionally kept empty or to exist before their contents exist. I've never seen anybody decide on something that doesn't.
Never heard about this, nor can I imagine what purpose it could serve.
This seems like splitting hairs given you can trivially derive one from the other.
There's nothing stopping a UI tool from figuring out that a file was moved or split into multiple files -- it just has to do so from looking at the state before and the state after. Git has gotten better at this over the years and keeps improving, so newer versions of git will be able to look at existing git repositories and synthesize better views of the history.
A CRDT type thing where your intentions are stored would be cool. The C means conflict free… just imagine!
There's a LOT of room for improvement, but there's no profit incentive for improvement, and let's be honest, git is very nice at it's price point, so we're likely at a local maxima for a while. Not the worst situation, but the world could be better.
Disclosure: I spent the 90s working on a different source code management system. People have _opinions_ on what makes a great SCM, and it's definitely not 'one size fits all'.
There was no profit incentive for creating Git. It still got created and became popular.
It's just that Git is far closer to good enough than what came before it - many of those were true horrors (I'm looking at you ClearCase).
That's not the whole story.
There was lots of profit incentive behind Github. And is was Github that won, not Git. Git was carried along as a parasite.
I love GIT and GIT is great for what it does, but most of the times I feel that what I need from a history is different than just text changes. Two simple examples: white-space changes and variable name changes could be ignored for some cases (of course, not for all, but that's the trick).
Such changes might be built on top of git (and some are today), but at some point new requirements might mean a different system.
--ignore-space-at-eol Ignore changes in whitespace at EOL.
-b --ignore-space-change Ignore changes in amount of whitespace. This ignores whitespace at line end, and considers all other sequences of one or more whitespace characters to be equivalent.
-w --ignore-all-space Ignore whitespace when comparing lines. This ignores differences even if one line has whitespace where the other line has none.
--ignore-blank-lines
What about white space sensitive language like Python (that's one of things I hate about the language)?
Diff also gets easily confused, because its context window is pretty small.
(A) If the thing you have in mind can be inferred by looking at two commits, then you don't have to record the intention of the changes into the version control system because you can compute it later when needed.
(B) If the thing you have in mind can't be reliably inferred by looking at two commits, then you need some other way to tell the version control system about your intention.
For example, if you're just re-indenting a python source file, are you going to:
1. expect the system to automatically/heuristically realize you're just re-indenting it --> see (A)
2. explicitly tell the system that you've reindented it when making the commit --> are you sure you're bothered to do that?
3. Consistently and exclusively use a specialized IDE that records all your actions and transforms it to the corresponding intentions as recognized by the version control system?
If your idea is to use heuristics to automatically infer intention during commit time and record it into the system, then obviously you can also do that in git after the fact by comparing two commits and running the same heuristic.
In most cases (except file move?), I doubt the intention of the changes are so easily/cleanly captured. You'll probably need to have some deep IDE integration (eg. so it knows you actually renamed all your variables using the refactor tool). I can't see that having widespread application at all.
One thing to investigate would be to include AST (abstract syntax tree) concepts in the source control or tools (although for comments might not solve the issue). Renaming a variable, moving a function around and other cases would be caught by an AST aware source control, but they are not today.
I can see how people who are into the simplicity of the git on-disk format don't mind the downsides, but I personally hate spending time handling concurrency-related conflicts that the system could have handled for me (some of which are probably because I or my coworkers did not do the right incantations in the right order).
Git hews too closely to immutable history, which is in tension with the simultaneous goals of code review and async development.
If code review is blocking for merges and results in comments that require altering commits, how to you continue work without waiting for review to complete?
You stack changes. But the problem of propagating review-driven edits through to your stacked changes remains.
Gerrit tries to fix the above on the server side by requiring every commit to be marked with a change id so edits to commits can be tracked. But it's not a great experience on the client side.
It's become kind of a cultural symbol for "developerness" though. This shifted the balance of shame. If you don't "get git" that isn't seen as a git problem. That's seen as a you problem. "You're" not a proper developer. This gives it a pass for sucking.
As such, the only people who can criticize it are people who know it back to front. Most other people (especially learners) will assume that if they don't get it that the problem is with them.
...they said, in a thread full of people criticising different aspects of Git without proving their git-expert credentials nor being accused of being the problem themselves.
I'm sure that as with pretty much any widely used thing there are both people who criticise it unfairly because they don't know how to use it for what they're trying to do, and also fans who over-defend it blaming users for not knowing every single little detail and sometimes blaming the user for a problem with Git. But it doesn't seem from what I've seen generally that it's a problem for anyone to criticise Git's flaws, just that there often isn't an answer to "well, what better alternative is there?".
HN tends to be a bit more open and less conservative than the average dev team.
The thing about horrible UXes is that you get used to them. Then once you know it back to front that becomes an impediment to switching. There's an entire generation of developers now who have grown up never having known anything other than git.
It was quite irritating to invest time not only in figuring out which was better initially (only to discover that this didn't matter), but to invest time learning the better one and then to lose all that investment in memorizing commands/keystrokes/concepts.
It's true that most of them map so it's way easier than picking it up from scratch, but it's still a hefty chunk of effort and the annoyance I felt because I felt like I shouldn't have to do this made it harder.
Mongo makes me rage for the same reason (but way worse). I know I could learn about its equivalents of indexes and foreign keys and materialized views or whatever but I honestly really just want it to fuck off and die and get replaced by postgres in every single situation where it is used. It is a genuinely shittier technology that grew popular on the strength of marketing (image) rather than quality and that is why I'm forced to learn it.
I do think the story with MongoDB in particular has a lot to do with marketing, but IMO the broader story is that objects (/ "documents") are actually a more natural fit for modeling the storage of application state in oltp databases than are relational databases (though relational databases are certainly unmatched for analytical use cases). I'd say that the popularity of MongoDB despite the relative weakness of its implementation of that insight has been more annoyingly detrimental to the object/document store approach than to the relational DB approach. That is, the backlash to "MongoDB doesn't work very well" has been "just use postgresql" rather than "we need a better document database implementation".
Coincidentally, just yesterday I was looking into pg's object store capabilities in order to suggest "use pg as a hybrid relational / document store" as a potential compromise solution to get to consensus in a relational vs. document-store discussion. But I found it pretty lacking, frankly. It's nice that jsonb exists, but its capabilities seem quite limited. For instance, it seems I can't use json-schema to define the schema of a jsonb column? (I did conclude that I need to do more research before rejecting this out of hand, but my initial research was not as promising as I had hoped.)
The thing that you can't easily criticize is that the UI isn't very clear and gives no confidence that what you are doing is actually correct. -- But I imagine at this point, it's safe :)
Other VCS out there do have better UIs, with concepts are are more clearly told apart (or not confusingly separated, like tags from commits). But none is so much better that it's worth abandoning everything an copying them.
Is it a bad thing? How can you have a consistent decentralized system without an immutable history?
If you alter a commit, you create a branch, it may not be explicit, it may be called another name, but there is no way around it. An altered copy of any kind is effectively a branch. In the same way, if I take your modifications to put them in my own workspace, then it is effectively a merge, no matter how you call it.
And long as you allow clones or even just backups, the history is immutable whether you like it or not. Changing a commit on your server won't change it from everyone's computers and tape backups, the real history is there, somewhere and no review is going to change that.
Git simply makes all that explicit. The history is immutable (it is effectively a blockchain), and every change is a branch.
Note: while the git history is immutable, the branch names are not, so you can simulate rewriting history by creating a new branch with the altered commit, and giving it the original branch name. The original branch will then be nameless, and may be removed from the server if garbage collection is active, but it won't make it disappear as it can still be present in clones.
As for change ids, it is not about commits, it is about tickets, something that git doesn't take care of, but it can be done at a higher level. Git only tracks changes, it doesn't care about your workflow. This is what Gerrit, GitHub, GitLab, Bitbucket/Jira, etc... are for.
The only git-native way to capture revisions is to use separate commits for every edit, and avoid squashing on merge. But then you have a history full of work-in-progress commits, which isn't great either - especially not great for git bisect. And separate commits still doesn't help with continuing work asynchronously while waiting for review to complete - you still need rebases, or merges (yet more weird history)...
Git is a little quirky with that kind of workflow because when you are making a merge commit, you don't really know which parent is which. There is a convention however, and it is that the first parent is the branch being merged on, and the others are the ones you merge from. Commands like git-bisect and git-log come with the --first-parent to avoid having your history polluted by broken work-in-progress commits. As for your asynchronous work, same thing, you can use merge commits, making sure the first parent is your work branch and using the --first-parent option to make sense of that mess.
The weird history problem is just a UI problem, which is actually the worst part of git. Its core is solid, but its UI, especially the command line is a mess.
Maybe, with a little compression, we have enough disk space to simply do both.
After squashing and rebasing, some normally-hidden data in the commit lets a client resurrect the original, highly-detailed commit graph including every "uh forgot to commit on Friday afternoon, dunno what this was but it's important" commit.
(Of course you can always redact sensitive data, as long as you control and trust every hard disk the data is on)
Is that supposed to be a good or even useful thing?
Commit messages (out-of-band) tie this information to the specific time when the change was made. They also don't clutter the code up.
Comments (in-band) tie this information to the specific place where the change was made. If overused, they make the code harder to read.
Commits can get lost in the noise, though blame and bisect can help find them. Comments can get stale and cause more confusion than assistance.
Honestly, if we spent more time reviewing and revising each other's code than just writing it, then comments (combined with refactoring for readability) would probably be the better solution. But that would slow down development. If you're going fast or lean, then relying on commit messages is better than nothing at all or fired-and-forgotten comments.
Commit numbers are an API and it's frustrating when I write something like "Fixed in commit xyz" or "Broken in commit xyz" or "Tested manually in xyz" and then after a rebase (Not a private rebase I asked for, but part of the CI routine), my comment makes no sense and Github says "We can't find that commit". You can paste it in manually but the context is lost, it's not in `git log --graph` anymore.
I personally hate seeing dozens of semantically meaningless pull-merge commits ("merged branch main into main"). I don't care when you pulled or what effect it had on your local history. When you push, push a clean linear history starting from where other people left off. If you spend too much time working independently on a "branch" (your version of main diverging from everyone else's version of main), then you're not collaborating and you're not continuously integrating your work.
I do like the idea of being able to compress the history you're squashing, though. There can be a lot of trivial commits, but depending on workflow, squash-merge can hide subtle things like the reason you made a very important one line change.
Really there is still no real alternative to Perforce when it comes to handling binary files. Previously PlasticSCM was a good contender but Unity bought it for their own version control system and seems they've stopped developing the original software (which is a shame...)
I've tried using it myself for just simple tasks and was pretty unusable - lots of weird bugs and unintuitive behavior... Can't really imagine how painful it would be for a mid-to-large size gamedev team.
The underlying graph model seems to be underappreciated by upper layers of Git, which instead tries to pretend that history is linear. Lots of useful graph operations like longest path between vertices are missing. Rebasing an entire isolated sub-graph should be possible too.
No it’s not. Git isn’t a model of textual changes. It’s just a model of textual snapshots connected over time.
If I were building a replacement for git, it would store character by character changes instead - though for that to work properly you’d want editor integration. Then the same tool could act as both a version control system and as a platform for realtime collaborative editing (via CRDTs). You can still have commits - they’re essentially just tags. And I’d keep the concept of branches.
Most of the algorithmic work has already been done - at least from the CS research side. Combine my work in diamond types with some of Martin Kleppmann’s work on BFT CRDTs & automerge. There’s a few more tricks needed. For example, you don’t want a hash on disk per keystroke. I’ve figured out a nice answer for that but haven’t written it up yet.
Deleting data is an unsolved problem. For example, if someone accidentally pastes in a password you need a way to prune it from the history. And async merges probably want to emit conflicts - which nobody has done on top of CRDTs yet as far as I know.
If I were building it, I’d also throw in a simple crdt based data store, synced over the same protocol. Then we could also store GitHub issues and other stuff inside the repository itself (a la fossil). CRDTs resolve conflicts better than git ever will, because they have access to more information than git does about what happened.
It’d be a pretty cool model. Definitely worthy as a successor to git in my opinion.
When researching the question of "Why did X occur?", I absolutely, positively, beyond a shadow of a doubt, do not want to filter through literally hours of keystroke-by-keystroke data. I need some sort of indication as to what states are worth looking at. Those are commits. Whatever further thing you may want to say about them, like "well, whenever the tests all pass we'll add a checkpoint", well, you can do that today. If you don't, it's either because you haven't thought of it, or the resulting multiplicity of commits is already too much to deal with.
Moreover, just having a CRDT history of keystrokes is an inadequate data structure for many things people do in git all the time. Merging a branch based on keystrokes is crazy; all you end up with is more opportunities for conflicts than the current system has. You think more information is good, I suspect in practice it would actually be bad. Git has no problem merging things where five people were working on a given repo at the same physical time, but on different things; a CRDT model would have to do weird things to have a sensible merged view after that, because a CRDT system is concerned with creating the final document; a source control system needs a human-meaningful history as well. (You can't just interleave their work, because the result moment-by-moment view would never make any sense. You can keep track by a branching mechanism where you can only go down one of their work path, but the natural implementation of that would have to not have the other branches available either. The problems go on; you actually end up with a much less flexible approach to slicing & dicing code without a lot more work, which is quite likely PhD-level work, assuming it's even possible.) Rebasing, if you are OK with it, effectively breaks CRDTs as you observe (it's the same basic issue as deleting something). CRDTs may effectively handle offline work getting merged back into the "main" online view but what CRDT setup is designed for browsing through history, and potentially pulling things back out of it?
I think if you actually tried to manifest this as the root level of a version control system you'd rapidly find it is full of problems, both theoretical and practical.
However, you could adjoin these capabilities to something like Git (or Fossil or Mercurial or whatever, I don't much care which). It's just instead of trying to build a single CRDT history that goes all the way back to the beginning of the repo, you adjoin a CRDT representation to commits, but allow each commit to serve as the base of a series of CRDT transactions on its own terms. So a merged or rebased commit could still be traced back to its original, which would contain all your information that you're looking for, but the general manipulations of commits would still look like a current system. IIRC, git allows you to stick arbitrary metadata on to commits which can themselves be blobs, so if you have an editoring system that can emit CRDT information from an edit stream, you could prototype this right now with a bit of wrapping around Git (or, again, any other source control that has that capability) that adds the CRDT stream as metadata to the commit. Get a feel for how it works, see if it is as useful as you think, and then if it is, you can go forth to prove the rest of my message wrong by trying to build something where it's the base abstraction instead of an adjunct.
I would also encourage you with the fact that Linus wrote the first, useful version of git very quickly. A slick, polished source control system is a big task, but a source control system, one that mostly works, may ignore some corner cases, doesn't have any handling for symlinks, punts on file system case differences, probably has O(n^2) algorithms that break if you try to stuff it full of gigabytes, is covered with disclaimers to store no real data in it yet because it may break, etc., is actually not too hard. Proving my skepticism wrong via prototype is not necessarily that difficult.
I would welcome some tool that could guess/infer where some commit points should be, even if I didn't explicitly commit at those points. I often tend to jump about between files when debugging/tracing a problem, making some changes here and there, then... when it's fixed... I don't always have a good frame of mind to commit as cleanly as I'd like. Something that could try to group changes together - by function, or type of change, etc - and propose those commits would be helpful. I've not tried some of the coding AI tools in that respect - maybe they do that now? I've only ever read about "they can write good commit messages for you!" as a selling point.
Merging is also fine. How do you think CRDTs work? You know merging is the entire point, right?
I agree that the system needs to handle both synchronous edits (peer programming) and asynchronous edits (the kind of editing we do now with git). CRDTs can handle separate concurrent branches just fine. It’s just none of the existing crdt libraries support branches.
You’re right that rebase is weird in CRDTs, but I think we can still build it if we need to. Rebase is mostly used in git to work around one of git’s design flaws: Git is never sure if commits should represent the actual history of changes, or the semantic history of merged tickets. But a better system could just separate those ideas anyway.
Yes, it is a PhD level problem right now. But so was diff-match-patch a few years ago. I’m an expect in this field. And I believe we now know how to solve all the sub problems here - all but one: how do we actively generate conflicts from asynchronous edits in a crdt? That needs to be figured out first.
What if I'm trying to fix a bug, and so testing a file, while someone else's edits are being applied to it. That would be painful
CRDT would be great in many ways, but I think for programming I would most often want to reduce the variables, and not see other people's edits until commit/merge
Would CRDT still be useful in that context?
Unfortunately, none of these efforts have ever panned out. I cannot claim that they are unable to work, but they have not done so, yet. And I'm not clear on why that we think they will.
From evidence I have seen, there is no magic data structure that can help resolve conflicts. Pretty much period. The only algorithm that always works is to bounce it back to a user. With LLMs gaining in power, I suppose you could lean on one of them for the first non-mechanical pass?
Which sucks, because quite frankly CRDT and friends are fun data structures. But, they make the easy and trivial cases much much harder. Which is why a series of snapshots is far more effective. Those snapshots are not for the convenience of the tool tracking changes. They are for the convenience of every other tool that you are using.
CRDTs (and similar algorithms) can do a whole lot better than git does today. They simply have more information to work with about what changed, and where. Git has to reconstruct that from re-diffing snapshots - which is always a lossy process.
It hasn’t been done because until recently (the last few years), CRDTs were considered too slow for practical use. It’s just recently that we as a species figured out how to make them fast and lightweight.
That is, the cheat, I feel, is that most of what anyone does with anything from source control, is to work with the snapshot. Building a diff between trees is surprisingly rarely done. Yes, you see the reconstruction of one every time you run `git log -p`, but by and large, that is not what you work with. (And this is ignoring that you often want to see the diff between two tree heads...)
Now, you seem to be pushing to change this and to have people always work with the CRDT for everything they do? Does this not push it so that the source control now becomes something that every editing tool in use has to also work with it?
Aside, I'm also not at all clear that CRDTs have gotten to the point that they can do octopus merges at a reliable rate. More, I'm not clear on what merges actually look like with CRDTs, in a source control sense. Happy to see any reading, if you have a link.
I don’t have a link at the moment, but I’ve ported editing traces from git (by re-running diff match patch) and used CRDTs to do octopus style merges. They merge fine - just as you’d expect. (As I said earlier, the hard problem is adding back any conflict markers so humans can eyeball the result).
There’s nothing special in doing branches. You just only merge the set of edits (crdt messages) that show up in any particular branch’s history.
The fact that most people using git don't refer to the snapshots as a thing is pretty much how invisible that is to all of our tooling. It isn't a special thing, it is the thing.
If you are pushing for a state based crdt that can be reconstructed from snapshots, then you aren't needing to change get as a whole, but only the diffing tool? If you want all diffs to be based on the edits users did, you aren't wanting to change get, as much as all of the tooling users use. No?
The biggest problem with git is anything that isn't just text (e.g. binary files). What's needed is a source control system that understands binary file formats well enough that it is capable of producing a user (developer) friendly diff.
For example, if git understood PNG you could do a diff on two versions of that PNG and it would show you that e.g. a color was changed or a TM symbol was added or similar.
I think git will be with us for a long time but whatever replaces it will be able to handle binary diffs in an intelligent way. Probably with AI-generated summaries.
Even then it might still be git... Just an improved version.
If a png is stored in a repository and changed, then logically the repository contains two snapshots identified by hash.
When a user tool (or git itself) wants to display the diff, it can be as creative as it wants in figuring out how to render that diff, including understanding file formats.
When git itself wants to store the two images, it has to do so with bitwise fidelity. Nonetheless, as with text files, it is totally possible for it to represent it internally as a delta-compressed view of the file, which, for an image file format, might be more compactly represented than by looking at the binary difference between the files. So long as this can be done deterministically and reproducibly, this is something that can make storage of large files more compact over time.
The same with handling image files.
Both of these “downsides” don’t make sense for me. I make set of changes that make sense, if character change makes sense to be historically relevant I make a commit. Yes it is a lot of work but I make choice what is relevant and what is not and put it in a commit. (changing text layout and white paces can be relevant on its own ;))
On the other hand I fail to see how bit level changes of an image makes a difference. Image is all or nothing the same executable file. Patching parts is 99% of time not relevant or simply not something people do or care about.
There are two issues that you touch on here, though. One is data storage. There is nothing stopping git from storing those snapshots as deltas from previous snapshots, so long as it is able to reproduce the tree at any point in time with bitwise fidelity.
Already, internally, git will store deltas to compress the store instead of storing content for each changed file.
And at display time, it can make inferences about what has changed between two snapshots. So over time history gets "better" as it tracks file and line moves better just by making better heuristics around how to present changes to the user.
The main defect you point out is the immutability of history, especially when it comes to deleting history. I don't really have an answer for that, and I'm not sure that this is a solvable problem when you have a distributed version control system -- no matter how much you try to purge something, someone somewhere can have a copy of the unpurged repository so the idea of a definitive "delete" sounds incompatible with a distributed vcs.
A better way would allow you to push your changes as stacks of commits. No branches. Just push, and have a CI that automatically builds, tests, merges and deploys your commits. And everything that didn't pass gets handed back to you. Instead of change reviews, do pairing and code reading sessions.
I would argue this is a lack of imagination more than attaining a global maximum.
Wikipedia - collab code and it just keeps everybody's edits and you can branch wherever.
Google Docs - inline marking and writing all over the code. Color segments for different users, ect...
I got a laugh out of that line. Hard to think that you could be “one of the first” in 2000! I guess we all have different perspectives of time.
Also might be worthy to mention Jujitsu [0], a vcs out of Google with a git-compatible backend and more ergonomic interface [1].
[0]: https://github.com/martinvonz/jj
[1]: What if we could replace Git, Jujutsu might give us a shot https://v5.chriskrycho.com/essays/jj-init/
Git: April 7th, 2005
Github: April 10th, 2008.
So Git will be 20 years old next year, and Github is only 4 more years and about a month short.
That's staying power I am hesitant to just handwave away.
Also, I am reminded I am an ancient relic. Has it really been that long? Damnit.
The only thing that I can see ever replace git is something that is fully backwards compatible with git and insanely intuitive and possibly extents git or replaces it, but again key thing would be 100% support for regular git repositories, if people enjoy using it with existing git codebases thats step 1. Im not sure if anybody is even trying to engineer such a thing, and lets say they have 100% backwards compatibility with git, what would you change about it to migrate into? Do you keep the same exact underlying git but the commands are more ergonomic somehow? Or are there alternative approaches to how git stores code that could be more efficient somehow?
It takes someone making something better but also compatible with the dominant offering.
Sidenote I had a coworker who worked with people using SVN but he kept a git branch still so he could more easily revert code and experiment, I forget his approach but it seemed to work. I assume the repo from git was a layer above the SVN directory maybe. This goes back to what I am saying though, even though its a little different he was able to still satisfy the needs of the client with their tooling but still use tooling that hes productive on.
You can drop it in and work seamlessly from git repos
Or it'll all just be done by LLMs then.
(And it's totally possible GitHub will still be there in 20 years - we're still all using Windows and macOS and Unix, aren't we?)
It'll be interesting to see if this plays out, or if git (and github) have reached some sort of local maximum in VCS where it does enough for most people that there's not much benefit to moving to a new tool.
Of course there might be some massive leap in VCS technology, but it'd be hard to predict.
Even after using git for years now (and having been forced to use CVS in the 2000s) , I feel that git is an evolutionary plateau. A really good one. However, I wish some features of the tightly integrated IDEs from e.g. Rational could see a revival.
I'm not sure I used a pure IDE from Rational though, so maybe that was better?
https://git-man-page-generator.lokaltog.net
Worth correcting to share that site.
> These days, we are used to cloning an entire project on our computer, after which we can safely plug it off the network and continue writing software in a completely disconnected way. This simple paradigm was utterly and completely unthinkable 20 years ago.
I was doing this with CVS or SVN over 20 years ago. (For "https://www.neilvandyke.org/linux-thinkpad-560e/".)
Even 20 years ago, you could reasonably assume regular online connections.
I don't know what happened here, with this amnesia - twenty years ago, my CD stack was vital for some things - if only for finding code samples in the comp.lang.c archives that I long had on rotation in the multi-CD selector.
Thirty years ago, you had to have books. And magazines.
Fourty years ago, a guru friend.
If the premise is "I can work on this locally", then you could do this since forever by just having a local directory...
Merges in SVN and CVS were also very painful to do. After being bitten by it, every single place I worked at had to create protocols and guidelines on how often to merge/reconcile code to not waddle in a eventual merge hell.
VSS, CVS and SVN were ok to use when there were no other choices, Perforce was really good but very expensive, git and hg felt like the future when they showed up.
The merge logic were pretty much identical for git and svn. The reason git is so much more advanced now is that is has improved a lot while svn doesn't see that much development anymore.
I agree that git and hg felt like the future, and bazaar and arcs before them, but mostly because they represented another workflow very different from other products, not because of some specific technical reason. Version control is a network effect and you don't see the gains until everyone agrees on a common workflow. The rest is an implementation detail. OpenBSD is famous for being a strong culture around their cvs for example and it works for them.
A local SVN repository worked miles better. But house policy was VSS.
Subversion?
I used subversion for an entire decade at one job and never ran into this, in fact, I did not even know it was possible in subversion.
When it happened with VSS before that we just got an admin to unlock the file(s) on the server.
>Merges in SVN and CVS were also very painful to do. After being bitten by it, every single place I worked at had to create protocols and guidelines on how often to merge/reconcile code to not waddle in a eventual merge hell.
I've just never had any issues with merging. shrug.
>VSS, CVS and SVN were ok to use when there were no other choices
I've used all three professionally and VSS never felt "okay" to use, it was very slow, super clunky, and prone to data loss and corruption. I would back up my files before commiting to VSS. You also just simply just can't view history of a folder if it was really big - the operation would just never complete. Basically, using VSS was just terrifying.
Commit here approximates to a push in git terminology. The intended use is a little bit different. Normally you wouldn't have committed until you were really done with the work (and all reviews etc) since there is really no concept of a rebase. So a commit is really something you "commit" to. You work on the patch instead.
Some of the difference is from the tools, but some of this is also due to the difference between a patch based vcs and content addressable one.
Keep in mind that the intended workflow with svn is to perfect a patch locally and commit when you are done. So something like svk is considered a special case, not an integral part of the workflow. git actively encourages you do split your work in separate commits using rebase.
So there is a big difference in intended use, perhaps not as much in technical ability. Linus would likely have gone mad had he forced his workflow on svn.
This feature also sets a hard limit on the size of your project, its files, and its history: it's limited to the smallest laptop of a developer.
Most of the time this doesn't matter, but alternative (often terrible) VCS still exist in industries where the files are much larger such as game development, video production, and chip design.
I don't remember CVS having one out of the box, and just checking out a working copy via `pserver:` would leave you with a tree you couldn't even `diff` in a disconnected state IIRC.
...but also, if you create a local clone of the whole repo, and then commit a series of patches to it, how did you even manage to keep track of which ones weren't in upstream? I mean, keeping track of patches with the external `cvsps`/`quilt` tools wasn't monstrously difficult (even if it wasn't especially easy, either), but keeping track of which patch sets were in one repo but not another?
So I think keeping the entire version history on a local hard drive was doable 20 years ago, but I think you’re ultimately right that keeping history locally would have been a less appealing solution.
[0]: https://www.tomshardware.com/reviews/15-years-of-hard-drive-...
[1]: This is just based on what I happen to have checked out locally, but it includes Rust and CPython.
Of all words I could utter to induce fear and an instant panic attack in any technologist: "Microsoft Visual SourceSafe"
Caveat: I'm not a dev.
I think it should be ok for bigger projects, I mean sqlite uses it, but I've no knowledge about whether it's considered big or not other than Sqlite being on every device (more or less).
Help appreciated!
Sadly, though, realizing it got iffy when you strayed from the well-trodden path hurt my opinion of fossil a bit.
[Edit] My use case is that I ported pikchr (and lemon) to Go and want to be able to notice changes to both. Like everything from the SQLite folks, pikchr is amazing.
[0]: https://developsense.com/visual-sourcesafe-version-control-u...
When I started, in 1994 we did use source control. We zipped up our changes and sent them to The Guy Who Merged them into the code-base using a commercial version of emacs, that nobody else in the company used. That's source control, right?
I had read somewhere that Linus coded the first version of git on an airplane ride.
So Linus essential wrote a data model, and others implemented the logic. The UX was always a train wreck because there was no UX.
Focusing on the data, then the logic, and punting the presentation layer has proven a unique and pervasive way to do a piece of software.
One is skeptical that this can be repeated for much of anything else. The reality that this originated as a linux kernel support tool is probably another factor in its rise.
Git knocks them all into a cocked hat. Linus changed the world (again).
The one thing that I would like to see in Git, is true support for fractional repos (setting up a "window" into a Git repo that only includes a subset of files). SourceSafe (another one that wasn't as bad as the comment mentioned) had one neat trick: You could create "aggregate" views, encompassing files from different repos.
(Edited because submitted too early :D)
For example, in all of my repos, I have massive test code. It usually far surpasses the implementation code.
It would be nice to be able to clone just the one 300-line implementation file, as opposed to the several thousand lines of test code.
Also, the “aggregate” workspace thing that SourceSafe used, would be a great help, for a lot of dependency hell issues.
Twenty years is nothing.
Why can't I pull all the PRs from a git forge to grep through them locally?
Well, maybe someone did try to figure that out and perhaps even did, then I don't understand why that never popularized.
The biggest whoopsie with SVN, in my experience, was "externals". That was both a bodge and a footgun, and got me into trouble more than once.
Just look at the concept of an MR, thats so, well used these days we forget that was not always a super thing and that many projects did and do use git over email
Actually it was perfect for solo use. It was the team use (on a network share of course) where it would get corrupted. You had to make regular backups!
What makes that information important?
> about what branch changes came from
Is it even "what branch"? Most of time I'm rebasing my changes from one commit on `main` onto a slightly newer commit on `main`, and when they're finally ready to be reviewed/pushed publically, I'll rebase (and fix) them onto the newest commit on `main`.
And I'm generally not doing it so the commit graph looks prettier. I'm doing it so that the changes are as self-contained and as easy to review (either now, or at some point in the future) as possible, because the merge commit is as simple as possible. (If it's even necessary.) If a merge commit involves a bunch of differences from both parents, that can be tricky for people to reason about.
However, most development is done at least partially centralized where you have a real "source of truth" and everything else is derivative/subordinate to that. In that environment, there is little reason to have the entire history of everything on your machine since you can always call out to the real source. It is the clone having everything that causes problems with binary files and large code repositories since a clone must download the entire universe unless you are very careful. Companies work around this limitation by doing clever virtual filesystem hacks that act as-if you downloaded the whole thing but actually only demand load in things as needed allowing them to transparently work with large repositories without the crippling download/storage costs of every random laptop actually holding the universe.
This does not mean we should go back to centralized version control systems where everybody is only a client. In that model you must reach out to the source of truth for everything and every branch only exists if the source has it. No, what we need is a system where you are a client and a subordinate (up to full/peer) server. You pull a subordinate server with as much, temporally and spatially, of the true server as you want. You can then operate as you can in git creating branches and as many local commits as you please with your subordinate server tracking those changes. You can then synchronize the real server with the sub-server as you do in regular old git. The logic should all be basically the same, since sub-server synchronization is actually a simpler, degenerate case of the synchronization of true peers which git does normally.
You can also create a chain of sub-servers, what are basically mirrors of various completeness, to support whatever degree of centralization to distributed you want. No, central system, but also not fully distributed; a hierarchy as deep or flat as you want supporting both extremes in one model while incurring minimal structural differences or complexities above the currently used fully distributed model.
This provides the development advantages of a monorepo while retaining the infrastructure advantages of the multirepo. You can just create spatial sub-servers for each "logical" repo that the primary development team on that component pulls from normally. If you need to reach outside you pull either multiple sub-servers or the parent. The advantage you get over multirepos is that your sub-servers know they are actually one whole, so pulling multiple "repos" and simultaneous commits will not result in bizarre history tearing or figuring out how to synchronize the disjoint histories, which are some of the major advantages of a monorepo.
You can handle binary assets or files easily because you just set the main development sub-server to not include the assets and their history. Maybe you have a test sub-server that when pulled only pulls the current version of the assets and nothing more so you can build the newest version. Not like you need the entire history to build with every random old version of the assets. But again, by having a unified version control for the assets and the code you can know if your local server is out-of-date while still working totally locally until you need to synchronize.
While you are at it I guess you can fix the git UX as well, but the real prize is improving the model.
I know people who still make zip/tarball copies of source trees because they don’t trust git, etc.
I must admit I have occasionally used git as a tool for transferring files (https://xkcd.com/949/).
#!/bin/sh -e
TARGET=../$(basename "$(pwd)")@$(date --utc +'%Y-%m-%dT%H:%M:%SZ').tar.gz
tar czf "$TARGET" .
-- Linus Torvalds
(not really, but almost)