13 ms·

Twenty years is nothing

225 points by ingve 3y ago

Lutzb 3y ago
Got a good chuckle out of https://git-man-page-generator.lokaltog.ne https://git-man-page-generator.lokaltog.ne . 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.
- zellyn 3y ago
  Seeing Rational Rose, ClearCase, etc. mentioned without expletives is novel! My impression of that family of tools was not favorable. They worked… ok at first. But were slow, and if things got messed up, recovery was very difficult. Also, I once found an entire install of Perl down in the directory structure of a Rational product! I'm not sure I used a pure IDE from Rational though, so maybe that was better?
- martinpw 3y ago
  Looks like you lost the last character of the URL. Should be: https://git-man-page-generator.lokaltog.net https://git-man-page-generator.lokaltog.net Worth correcting to share that site.
fifilura 3y ago
"There are two interesting contenders worthy of mention: Pijul, written in Rust" 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.
- zellyn 3y ago
  I personally find the mention of the implementation language as part of a project description to be slightly interesting/informative, or at worst benign. Unlike the inevitable comments complaining about it. 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 https://wiki.mercurial-scm.org/OxidationPlan, which discusses reimplementing parts of Mercurial in — you guessed it — Rust.
  - fifilura 3y ago
    Thank you! And informative. Some days are just like that. Your synapses trigger on something because of historical reasons.
    - michaelt 3y ago
      > 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.
      - pmeunier 3y ago
        Wait, nobody in the Pijul team brags about being in Rust. If Pijul were written today it would probably be in Zig, for many reasons.
        zellyn 3y ago
        I'm fascinated by this. I like both Rust and Zig, but I would have guessed that for the kind of complex data structure manipulation required for CRDTs and other clever algorithms Pijul employs, the degree reliable correctness Rust gives you would win out. Are you doing something (like entity-component models?) that disables much of Rust's smarts? Or is it just that much more pleasant to program in Zig?
- yard2010 3y ago
  Because language is everything. There is no such thing that sets the context such as language, whether a spoken language or a computer language. You would never understand the "true" meaning or words without knowing the language.
- DarkNova6 3y ago
  I believe this is twofold: 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!
  - anonzzzies 3y ago
    > apprehensive in using tools written in it) 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.
  - gwd 3y ago
    3. Someone who deliberately chooses to use Rust is someone who cares enough about the program being correct to put up with the borrow checker and all that entails. This increases my expectation of the quality of the resulting program. 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
    - GardenLetter27 3y ago
      Go also does the latter to be fair. If it weren't for Rust, I'd use Go. But Rust's development tools are incredible with rust-analyzer, clippy, etc.
      - gwd 3y ago
        Well yes, and I'm also more likely to install a random golang tool than a random python tool. :-)
      - marcosdumay 3y ago
        The one point on the list that Go doesn't automatically bring is #3. All the others are there. 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.
- gwervc 3y ago
  To prove that at least a single piece of novel software was ever written in it. It's an improvement over the decade we had here and elsewhere of people asking devs to rewrite their software with it; a phenomenon big enough to have it's own acronym (RIIR).
- odiroot 3y ago
  Maybe because it's also an attempt at marketing as well.
- aredox 3y ago
  The ancestor of pijul is darcs, whose main weak point was slowness. Git is very simple (simplistic) in its design (in use it is another story), patch-based VC isn't.
  - zellyn 3y ago
    I think the algorithms and data structures in Pijul have been carefully designed to be fast over a decade, and one of the original points of departure was making high-level decisions to facilitate performance. I know performance optimization in a lazy language is a special art, but I don't think it's Haskell vs Rust that makes Pijul fast. I'm sure the author can weigh in here.
    - pmeunier 3y ago
      Yes indeed, we would not have started Pijul without the hope that at least theoretically, patch-based designs could be faster than snapshots. "Patch-based is slow" without any other argument is not a very informed claim, Pijul is actually faster than Git in some cases (in fact Pijul is faster where it matters most IMHO: large files and/or large repos, conflicts and blames). Not because we're better at tweaking C code (we're definitely not!), but because we designed our datastructures like theorists, and only then looked at how (and whether!) to implement things. One advantage we had over Linus is that we had no time pressure: we could well use Darcs, Git, or Mercurial to write Pijul initially (we used Darcs, actually), and it didn't matter much if we failed. 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.
- jodrellblank 3y ago
  > "so I doubt possible added performance can matter much." 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."
- lemper 3y ago
  because it has nothing to offer so it appeals to certain audience. there, i said it. p.s., i know it's good stuff. but still.
- _xerces_ 3y ago
  Reminds me of an old joke among auto enthusiasts: "How do you know if someone drives a manual transmission? They'll tell you".
  - pif 3y ago
    Only a kid may consider it worthy to mention driving a manual. Manual transmission is the natural state of things. If you can't drive manual, you can not drive.
    - fifilura 3y ago
      Are you from Europe?
      - pif 3y ago
        Yes, I am. Does it matter?
  - munificent 3y ago
    The most profound dilemma in life is a vegan, rock-climbing, manual-driving, Crossfitter trying to decide what to tell you first.
    - fifilura 3y ago
      In Sweden she would tell you she is winter swimming.
- quesera 3y ago
  > Why is it that every time something is written in Rust, it needs to be mentioned 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. No good answers to my question, unfortunately.
- pmeunier 3y ago
  I can answer that question, as both the author of Pijul and as someone most Rust zealots usually don't like very much. 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.
  - Sammi 3y ago
    Is there a good video introduction to Pijul? 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 :)
- LegibleCrimson 3y ago
  Because mentioning it works. As somebody who uses many different languages professionally, I immediately assume projects written in Rust are more reliable, more robust, and more efficient. My own projects are higher quality when I can use Rust to implement them, despite having much more experience with most of my other languages. 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.
- sanderjd 3y ago
  If it's closed source, it makes no difference what the implementation language is. But if it's open source, it matters because part of deciding which open source tools to use is considering whether you would or wouldn't be comfortable fixing issues or contributing features yourself. Rust in particular seems to have developed into a net positive signal in this consideration. But it's also useful information for people who see it as a drawback!
- shp0ngle 3y ago
  One of the reasons git got popular is that it's FAST. One of the reasons is that's in C.
neilv 3y ago
Good article, but I might be misunderstanding this one bit: > 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/ https://www.neilvandyke.org/linux-thinkpad-560e/".)
- dudinax 3y ago
  How do you commit to CVS when you're off the network?
  - deleted 3y ago
    [deleted]
  - whiplash451 3y ago
    I don’t think you can. But you can still work on your project and commit when you get back online. Even 20 years ago, you could reasonably assume regular online connections.
- boffinAudio 3y ago
  Yeah, twenty years ago, it was quite important to already have everything onboard that you might possible need, when the modems didn't work. 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.
- the_duke 3y ago
  You can't commit locally with either CVS or SVN, if I remember correctly? If the premise is "I can work on this locally", then you could do this since forever by just having a local directory...
  - 3y ago
yawboakye 3y ago
an aside: de programmaticā ipsā is the correct latin (macrons can be elided just fine). i wonder why people would reach for latin but don’t bother to do even the irreducible minimum amount of work to ensure that they got the expression right.
pcl 3y ago
”24 years ago, Joel [Spolsky] was one of the first influencers of the burgeoning field of software engineering.” 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.
- whiplash451 3y ago
  One of the first influencers, not the first random nobody
  - zem 3y ago
    dijkstra would like a word! (as long as that word isn't "goto")
    - pjc50 3y ago
      I don't think he'd appreciate being described as an "influencer", though.
      - miroljub 3y ago
        Why do you think Spolsky would ;)
    - troupe 3y ago
      Dijkstra's blog posts were handwritten with a fountain pen and distributed by being photocopied. :)
      - munificent 3y ago
        What a hipster. Probably drove around in an old Volkswagen bus too.
    - ivanche 3y ago
      He's a computer scientist, not a software engineer.
toadi 3y ago
You remember CVS hell yeah and SVN too ;) Fuck am I getting old...
- bombcar 3y ago
  projrc3.zip I know people who still make zip/tarball copies of source trees because they don’t trust git, etc.
  - bloak 3y ago
    Meanwhile, other people trust git so much that they treat it more as a tool for doing an incremental back-up than as a distributed VCS (git commit -a -m x && git push). I must admit I have occasionally used git as a tool for transferring files (https://xkcd.com/949/ https://xkcd.com/949/).
    - Joker_vD 3y ago
      I am actually doing exactly that to manage my personal KeyPass database, down to using "x" as the commit message; it works reasonably well since GitHub allows you to download files with just HTTPS.
  - Joker_vD 3y ago
    Eh, there is nothing particularly wrong with #!/bin/sh -e TARGET=../$(basename "$(pwd)")@$(date --utc +'%Y-%m-%dT%H:%M:%SZ').tar.gz tar czf "$TARGET" . You can even add a fourth line to upload it somewhere automatically...
  - Karellen 3y ago
    > Only wimps use version control: real men just merge patches from their email inbox, upload release tarballs on ftp, and let the rest of the world mirror it ;) -- Linus Torvalds (not really, but almost)
animaomnium 3y ago
> There are two interesting contenders worthy of mention: Pijul [and] Fossil 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 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/ https://v5.chriskrycho.com/essays/jj-init/
- zubairshaik 3y ago
  I am personally surprised that TFA didn't mention either jj or Sapling [0] given its emphasis on how both Git and svn were both made to be backwards compatible! [0] https://github.com/facebook/sapling https://github.com/facebook/sapling
  - pmeunier 3y ago
    Not the same category of tools: Pijul and Fossil have radically different designs, whereas jj is a Git frontend, and Sapling a Mercurial fork.
taco-hands 3y ago
This article has made me feel decidedly old, given that I've used all of the repositories listed at one time or another. Of all words I could utter to induce fear and an instant panic attack in any technologist: "Microsoft Visual SourceSafe"
- pjc50 3y ago
  "Rational Clearcase"
  - brabel 3y ago
    I started using that with the IBM version of Eclipse IDE (what was that called??). I remember having to wait for people to come back from vacation to unlock a file they were editing otherwise no one could change it :D.
ozim 3y ago
What comes after GIT? 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.
- 0xfffafaCrash 3y ago
  Text is too broad a category for version control for software to be convenient. I would much prefer version controlling on a subset of text that correctly parses to a domain specific AST. Imagine how much better and informative the diffs and conflict resolution and blames would be. Also imagine moving code across files, e.g. by splitting them and actually having your version control understand that. You could probably push bisects and the like to new levels.
  - dagw 3y ago
    At the same time text is to narrow a category to cover many project needs. There are lots of projects where needing manage and version GBs of various binary data is vital. Git defaulting everything being plain text will miss out a lot of special cases where are more specialised tool might help, but on the whole is probably a good balance and 'good enough' for the vast majority of use cases.
    - dagw 3y ago
account-5 3y ago
I much prefer fossil to git in almost every metric. I use fossil for all my stuff. Much easier to use, imo, and provides a lot of useful features out of the box. Caveat: I'm not a dev.
- livrem 3y ago
  I used it for all my hobby projects created in the last three years. I still use Git for everything else. Fossil is nice. I can't imagine using it in a big project with many developers, but it was never designed for that. As long as Fossil is around I will probably keep using it for all my projects. I still push some code to GitHub to share with others. They do not have to know that I use a simpler tool for development.
  - account-5 3y ago
    Yeah I like that it can export, so to speak, to git. 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).
- zellyn 3y ago
  I've spent ages trying to get an RSS feed for changes to a particular file (on the main branch) out of fossil. I can't tell if I'm misunderstanding some fundamental organizing principle, or if RSS feeds from searches/filtered paths is just so far off the important path that it's missing functionality. 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.
revskill 3y ago
Git rebase is still hard though.
- sherburt3 3y ago
  Git rebase always seemed psychotic to me, like you're intentionally removing important historical information about what branch changes came from so that you can make the diagram of your git database a little prettier.
  - Karellen 3y ago
    > intentionally removing important historical information 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.
quickthrower2 3y ago
I don’t think Sourcesafe was mentioned. I have some nostalgia for that monster. 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!
- eschneider 3y ago
  I absolutely LOVED Sourcesafe! As someone working on competing products, Sourcesafe's tendency to (very occasionally) eat a repo basically bought my house.
smitty1e 3y ago
In mentioning the myriad of git UX "porcelain" offerings, an important historical point is missed: Torvalds couldn't just implement git due to the BitKeeper license. 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.
calvinmorrison 3y ago
The thing is even if the git command is superceded i feel like it will remain the underlying tool. Like if someone wrote a better interface to git, I would still think it would be git underneath. 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
a1o 3y ago
git is amazing, it has a myriad of ways to play with the data it stores. I can't see myself changing from it as it's been the only one of the many source controls I have tried that managed to work in all the usecases I had for it. I use it even in webservers.
bregma 3y ago
CVS was a vast improvement over its predecessors. RCS was an improvement over SCCS. Networked drives were an improvement over floppies with sneakernet. Been there, used them all and more. Twenty years is nothing.
vertnerd 3y ago
It is sobering to realize that in twenty years, Github will probably be gone, and no one will be using Git anymore. I have used so many different version control systems, starting with PVCS in the 90s. Subversion, CVS, Mercurial, and others I can't remember the names of! I hate Git, but everything I've ever done is living in Github now. Where will it be in twenty years?
- Dalewyn 3y ago
  I got curious and asked Google when Git and Github were released. 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.
  - bombcar 3y ago
    Git (and almost GitHub) are closer to the release of the first version of Linux than today.
- giancarlostoro 3y ago
  Fossil is really interesting and Mercurial is probably one of the better git competing version control tools, but git is too ingrained to be replaced. 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.
angiosperm 3y ago
TIL that Firefox was on Mercurial until last year.
nmeofthestate 3y ago
> (As a side note, I started my professional career as a software developer in 1997, and nope, we did not use source control, not even CVS. 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?
denton-scratch 3y ago
I don't like git. I appreciate that it's great in certain very distributed environments; but I'm still using SVN, because my projects are not distributed, and I can do without the opacity of git. 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.
ferd 3y ago
Young devs won't believe it, but until the early 2000s, most companies used source control systems that forced you to LOCK any file on a centralized repo before you were allowed to modify it (MS's SourceSafe, ClearCase, Perforce)... This was often the case even if you just wanted to touch a file locally for some experimentation... insane. 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.
- hnfong 3y ago
  > 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.
  - troupe 3y ago
    > I'm not sure it is the win you're suggesting. I had brief stints with CVS and TBH it really sucked. What had you used that was better? CVS seemed like quite a step forward compared to RCS and the other available options.
    - hnfong 3y ago
      The point I was originally trying to make was that they all sucked before SVN came out. 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...
  - ferd 3y ago
    CVS certainly sucked by today's standards, and SVN was indeed a big improvement, and Git much more so. 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).
ChrisMarshallNY 3y ago
I've used just about all of the above (and a couple that weren't mentioned, like Apple's MPW Projector, and Voodoo). 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.
- kettleballroll 3y ago
  I don't know, I personally have a slight preference toward hg, the UI feels a bit nicer.
  - mrguyorama 3y ago
    HG has an infinitely better UX than git, right up until the exact second you screwed up something and committed it to the core repo, and now you have to figure out how to undo history in a system that doesn't want you to.
- aunderscored 3y ago
  This kinda exists now with the newer partial clone options: https://github.blog/2020-12-21-get-up-to-speed-with-partial-clone-and-shallow-clone/ https://github.blog/2020-12-21-get-up-to-speed-with-partial-... (Edited because submitted too early :D)
  - ChrisMarshallNY 3y ago
    Not sure that would work. 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.
Levitating 3y ago
Yet twenty years is also easily 1/4 of our entire lifes. We have such an incredibly short lifespan.
Jun8 3y ago
OMG, I realized while reading this that (1) I haven’t heard CVS or Subversion mentioned in a long time and (2) Spolsky probably needs an introduction at this point. Both of these point to the fact that I’m getting old! I had read somewhere that Linus coded the first version of git on an airplane ride.
- rcbdev 3y ago
  I know 20 year old college grads who work with Subversion in large firms - I guess Europe really is the old world in many ways.
hermitcrab 3y ago
SVN is still fine in 2024. I run a 1-man software business and see no need to take the time and effort to move to Git. I can see the benefits for a distributed team though.
wrs 3y ago
Man, I forgot all about SLM (“slime”). That thing was so awful. At one point the Windows team had to start using “merge windows” to make any progress, like the networking team gets exclusive SCM access to merge their code between 8 and noon on Tuesdays.
Veserv 3y ago
The biggest problem with git is that it is entirely a distributed version control system. In git you are always the client and the server. Your clone, normally, contains the entire history of development and all branches. In a fully distributed development model like Linux, this is a good design. 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.
moribvndvs 3y ago
20 years ago, I was using Visual Source Safe. The amount of time lost to corruptions from internal VSS bugs, deleting files forever, SMB issues (one of them being people editing files off it directly), its abysmal branching and pinning strategies, truly awful performance, etc[0]. was considerable. We tried TFS as soon as that was available, got rid of it in less than a week in favor of SVN. That was a considerable improvement until about 2010 when we got sick of constant merge headaches and poor performance and awkwardness trying to jump between branches. People slam on git a lot, but the number of incidents resulting in lost work or bad merges went from fairly routine to maybe a scant handful in the past 14 years, most of which could have been avoided by protecting mainline branches and tags from junior devs or just following good source control daily routines. [0]: https://developsense.com/visual-sourcesafe-version-control-unsafe-at-any-speed https://developsense.com/visual-sourcesafe-version-control-u...
iLemming 3y ago
What I really don't understand is why have nobody ever bothered to decentralize Pull-Requests and Issues data, just like the code sources. 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.

225 points by ingve 3y ago

Got a good chuckle out of https://git-man-page-generator.lokaltog.ne https://git-man-page-generator.lokaltog.ne . 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.

zellyn 3y ago
Seeing Rational Rose, ClearCase, etc. mentioned without expletives is novel! My impression of that family of tools was not favorable. They worked… ok at first. But were slow, and if things got messed up, recovery was very difficult. Also, I once found an entire install of Perl down in the directory structure of a Rational product! I'm not sure I used a pure IDE from Rational though, so maybe that was better?
martinpw 3y ago
Looks like you lost the last character of the URL. Should be: https://git-man-page-generator.lokaltog.net https://git-man-page-generator.lokaltog.net Worth correcting to share that site.

fifilura 3y ago

"There are two interesting contenders worthy of mention: Pijul, written in Rust" 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.

zellyn 3y ago
I personally find the mention of the implementation language as part of a project description to be slightly interesting/informative, or at worst benign. Unlike the inevitable comments complaining about it. 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 https://wiki.mercurial-scm.org/OxidationPlan, which discusses reimplementing parts of Mercurial in — you guessed it — Rust.
- fifilura 3y ago
  Thank you! And informative. Some days are just like that. Your synapses trigger on something because of historical reasons.
  - michaelt 3y ago
    > 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.
    - pmeunier 3y ago
      Wait, nobody in the Pijul team brags about being in Rust. If Pijul were written today it would probably be in Zig, for many reasons.
      - zellyn 3y ago
        I'm fascinated by this. I like both Rust and Zig, but I would have guessed that for the kind of complex data structure manipulation required for CRDTs and other clever algorithms Pijul employs, the degree reliable correctness Rust gives you would win out. Are you doing something (like entity-component models?) that disables much of Rust's smarts? Or is it just that much more pleasant to program in Zig?
yard2010 3y ago
Because language is everything. There is no such thing that sets the context such as language, whether a spoken language or a computer language. You would never understand the "true" meaning or words without knowing the language.
DarkNova6 3y ago
I believe this is twofold: 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!
- anonzzzies 3y ago
  > apprehensive in using tools written in it) 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.
- gwd 3y ago
  3. Someone who deliberately chooses to use Rust is someone who cares enough about the program being correct to put up with the borrow checker and all that entails. This increases my expectation of the quality of the resulting program. 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
  - GardenLetter27 3y ago
    Go also does the latter to be fair. If it weren't for Rust, I'd use Go. But Rust's development tools are incredible with rust-analyzer, clippy, etc.
    - gwd 3y ago
      Well yes, and I'm also more likely to install a random golang tool than a random python tool. :-)
    - marcosdumay 3y ago
      The one point on the list that Go doesn't automatically bring is #3. All the others are there. 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.
gwervc 3y ago
To prove that at least a single piece of novel software was ever written in it. It's an improvement over the decade we had here and elsewhere of people asking devs to rewrite their software with it; a phenomenon big enough to have it's own acronym (RIIR).
odiroot 3y ago
Maybe because it's also an attempt at marketing as well.
aredox 3y ago
The ancestor of pijul is darcs, whose main weak point was slowness. Git is very simple (simplistic) in its design (in use it is another story), patch-based VC isn't.
- zellyn 3y ago
  I think the algorithms and data structures in Pijul have been carefully designed to be fast over a decade, and one of the original points of departure was making high-level decisions to facilitate performance. I know performance optimization in a lazy language is a special art, but I don't think it's Haskell vs Rust that makes Pijul fast. I'm sure the author can weigh in here.
  - pmeunier 3y ago
    Yes indeed, we would not have started Pijul without the hope that at least theoretically, patch-based designs could be faster than snapshots. "Patch-based is slow" without any other argument is not a very informed claim, Pijul is actually faster than Git in some cases (in fact Pijul is faster where it matters most IMHO: large files and/or large repos, conflicts and blames). Not because we're better at tweaking C code (we're definitely not!), but because we designed our datastructures like theorists, and only then looked at how (and whether!) to implement things. One advantage we had over Linus is that we had no time pressure: we could well use Darcs, Git, or Mercurial to write Pijul initially (we used Darcs, actually), and it didn't matter much if we failed. 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.
jodrellblank 3y ago
> "so I doubt possible added performance can matter much." 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."
lemper 3y ago
because it has nothing to offer so it appeals to certain audience. there, i said it. p.s., i know it's good stuff. but still.
_xerces_ 3y ago
Reminds me of an old joke among auto enthusiasts: "How do you know if someone drives a manual transmission? They'll tell you".
- pif 3y ago
  Only a kid may consider it worthy to mention driving a manual. Manual transmission is the natural state of things. If you can't drive manual, you can not drive.
  - fifilura 3y ago
    Are you from Europe?
    - pif 3y ago
      Yes, I am. Does it matter?
- munificent 3y ago
  The most profound dilemma in life is a vegan, rock-climbing, manual-driving, Crossfitter trying to decide what to tell you first.
  - fifilura 3y ago
    In Sweden she would tell you she is winter swimming.
quesera 3y ago
> Why is it that every time something is written in Rust, it needs to be mentioned 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. No good answers to my question, unfortunately.
pmeunier 3y ago
I can answer that question, as both the author of Pijul and as someone most Rust zealots usually don't like very much. 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.
- Sammi 3y ago
  Is there a good video introduction to Pijul? 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 :)
LegibleCrimson 3y ago
Because mentioning it works. As somebody who uses many different languages professionally, I immediately assume projects written in Rust are more reliable, more robust, and more efficient. My own projects are higher quality when I can use Rust to implement them, despite having much more experience with most of my other languages. 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.
sanderjd 3y ago
If it's closed source, it makes no difference what the implementation language is. But if it's open source, it matters because part of deciding which open source tools to use is considering whether you would or wouldn't be comfortable fixing issues or contributing features yourself. Rust in particular seems to have developed into a net positive signal in this consideration. But it's also useful information for people who see it as a drawback!
shp0ngle 3y ago
One of the reasons git got popular is that it's FAST. One of the reasons is that's in C.

neilv 3y ago

Good article, but I might be misunderstanding this one bit: > 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/ https://www.neilvandyke.org/linux-thinkpad-560e/".)

dudinax 3y ago
How do you commit to CVS when you're off the network?
- deleted 3y ago
  [deleted]
- whiplash451 3y ago
  I don’t think you can. But you can still work on your project and commit when you get back online. Even 20 years ago, you could reasonably assume regular online connections.
boffinAudio 3y ago
Yeah, twenty years ago, it was quite important to already have everything onboard that you might possible need, when the modems didn't work. 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.
the_duke 3y ago
You can't commit locally with either CVS or SVN, if I remember correctly? If the premise is "I can work on this locally", then you could do this since forever by just having a local directory...
- 3y ago

yawboakye 3y ago

an aside: de programmaticā ipsā is the correct latin (macrons can be elided just fine). i wonder why people would reach for latin but don’t bother to do even the irreducible minimum amount of work to ensure that they got the expression right.

pcl 3y ago

”24 years ago, Joel [Spolsky] was one of the first influencers of the burgeoning field of software engineering.” 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.

whiplash451 3y ago
One of the first influencers, not the first random nobody
- zem 3y ago
  dijkstra would like a word! (as long as that word isn't "goto")
  - pjc50 3y ago
    I don't think he'd appreciate being described as an "influencer", though.
    - miroljub 3y ago
      Why do you think Spolsky would ;)
  - troupe 3y ago
    Dijkstra's blog posts were handwritten with a fountain pen and distributed by being photocopied. :)
    - munificent 3y ago
      What a hipster. Probably drove around in an old Volkswagen bus too.
  - ivanche 3y ago
    He's a computer scientist, not a software engineer.

toadi 3y ago

You remember CVS hell yeah and SVN too ;) Fuck am I getting old...

bombcar 3y ago
projrc3.zip I know people who still make zip/tarball copies of source trees because they don’t trust git, etc.
- bloak 3y ago
  Meanwhile, other people trust git so much that they treat it more as a tool for doing an incremental back-up than as a distributed VCS (git commit -a -m x && git push). I must admit I have occasionally used git as a tool for transferring files (https://xkcd.com/949/ https://xkcd.com/949/).
  - Joker_vD 3y ago
    I am actually doing exactly that to manage my personal KeyPass database, down to using "x" as the commit message; it works reasonably well since GitHub allows you to download files with just HTTPS.
- Joker_vD 3y ago
  Eh, there is nothing particularly wrong with #!/bin/sh -e TARGET=../$(basename "$(pwd)")@$(date --utc +'%Y-%m-%dT%H:%M:%SZ').tar.gz tar czf "$TARGET" . You can even add a fourth line to upload it somewhere automatically...
- Karellen 3y ago
  > Only wimps use version control: real men just merge patches from their email inbox, upload release tarballs on ftp, and let the rest of the world mirror it ;) -- Linus Torvalds (not really, but almost)

animaomnium 3y ago

> There are two interesting contenders worthy of mention: Pijul [and] Fossil 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 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/ https://v5.chriskrycho.com/essays/jj-init/

zubairshaik 3y ago
I am personally surprised that TFA didn't mention either jj or Sapling [0] given its emphasis on how both Git and svn were both made to be backwards compatible! [0] https://github.com/facebook/sapling https://github.com/facebook/sapling
- pmeunier 3y ago
  Not the same category of tools: Pijul and Fossil have radically different designs, whereas jj is a Git frontend, and Sapling a Mercurial fork.

taco-hands 3y ago

This article has made me feel decidedly old, given that I've used all of the repositories listed at one time or another. Of all words I could utter to induce fear and an instant panic attack in any technologist: "Microsoft Visual SourceSafe"

pjc50 3y ago
"Rational Clearcase"
- brabel 3y ago
  I started using that with the IBM version of Eclipse IDE (what was that called??). I remember having to wait for people to come back from vacation to unlock a file they were editing otherwise no one could change it :D.

ozim 3y ago

What comes after GIT? 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.

0xfffafaCrash 3y ago
Text is too broad a category for version control for software to be convenient. I would much prefer version controlling on a subset of text that correctly parses to a domain specific AST. Imagine how much better and informative the diffs and conflict resolution and blames would be. Also imagine moving code across files, e.g. by splitting them and actually having your version control understand that. You could probably push bisects and the like to new levels.
- dagw 3y ago
  At the same time text is to narrow a category to cover many project needs. There are lots of projects where needing manage and version GBs of various binary data is vital. Git defaulting everything being plain text will miss out a lot of special cases where are more specialised tool might help, but on the whole is probably a good balance and 'good enough' for the vast majority of use cases.
  - dagw 3y ago

account-5 3y ago

I much prefer fossil to git in almost every metric. I use fossil for all my stuff. Much easier to use, imo, and provides a lot of useful features out of the box. Caveat: I'm not a dev.

livrem 3y ago
I used it for all my hobby projects created in the last three years. I still use Git for everything else. Fossil is nice. I can't imagine using it in a big project with many developers, but it was never designed for that. As long as Fossil is around I will probably keep using it for all my projects. I still push some code to GitHub to share with others. They do not have to know that I use a simpler tool for development.
- account-5 3y ago
  Yeah I like that it can export, so to speak, to git. 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).
zellyn 3y ago
I've spent ages trying to get an RSS feed for changes to a particular file (on the main branch) out of fossil. I can't tell if I'm misunderstanding some fundamental organizing principle, or if RSS feeds from searches/filtered paths is just so far off the important path that it's missing functionality. 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.

revskill 3y ago

Git rebase is still hard though.

sherburt3 3y ago
Git rebase always seemed psychotic to me, like you're intentionally removing important historical information about what branch changes came from so that you can make the diagram of your git database a little prettier.
- Karellen 3y ago
  > intentionally removing important historical information 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.

quickthrower2 3y ago

I don’t think Sourcesafe was mentioned. I have some nostalgia for that monster. 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!

eschneider 3y ago
I absolutely LOVED Sourcesafe! As someone working on competing products, Sourcesafe's tendency to (very occasionally) eat a repo basically bought my house.

smitty1e 3y ago

In mentioning the myriad of git UX "porcelain" offerings, an important historical point is missed: Torvalds couldn't just implement git due to the BitKeeper license. 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.

calvinmorrison 3y ago

The thing is even if the git command is superceded i feel like it will remain the underlying tool. Like if someone wrote a better interface to git, I would still think it would be git underneath. 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

a1o 3y ago

git is amazing, it has a myriad of ways to play with the data it stores. I can't see myself changing from it as it's been the only one of the many source controls I have tried that managed to work in all the usecases I had for it. I use it even in webservers.

bregma 3y ago

CVS was a vast improvement over its predecessors. RCS was an improvement over SCCS. Networked drives were an improvement over floppies with sneakernet. Been there, used them all and more. Twenty years is nothing.

vertnerd 3y ago

It is sobering to realize that in twenty years, Github will probably be gone, and no one will be using Git anymore. I have used so many different version control systems, starting with PVCS in the 90s. Subversion, CVS, Mercurial, and others I can't remember the names of! I hate Git, but everything I've ever done is living in Github now. Where will it be in twenty years?

Dalewyn 3y ago
I got curious and asked Google when Git and Github were released. 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.
- bombcar 3y ago
  Git (and almost GitHub) are closer to the release of the first version of Linux than today.
giancarlostoro 3y ago
Fossil is really interesting and Mercurial is probably one of the better git competing version control tools, but git is too ingrained to be replaced. 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.

angiosperm 3y ago

TIL that Firefox was on Mercurial until last year.

nmeofthestate 3y ago

> (As a side note, I started my professional career as a software developer in 1997, and nope, we did not use source control, not even CVS. 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?

denton-scratch 3y ago

I don't like git. I appreciate that it's great in certain very distributed environments; but I'm still using SVN, because my projects are not distributed, and I can do without the opacity of git. 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.

ferd 3y ago

Young devs won't believe it, but until the early 2000s, most companies used source control systems that forced you to LOCK any file on a centralized repo before you were allowed to modify it (MS's SourceSafe, ClearCase, Perforce)... This was often the case even if you just wanted to touch a file locally for some experimentation... insane. 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.

hnfong 3y ago
> 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.
- troupe 3y ago
  > I'm not sure it is the win you're suggesting. I had brief stints with CVS and TBH it really sucked. What had you used that was better? CVS seemed like quite a step forward compared to RCS and the other available options.
  - hnfong 3y ago
    The point I was originally trying to make was that they all sucked before SVN came out. 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...
- ferd 3y ago
  CVS certainly sucked by today's standards, and SVN was indeed a big improvement, and Git much more so. 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).

ChrisMarshallNY 3y ago

I've used just about all of the above (and a couple that weren't mentioned, like Apple's MPW Projector, and Voodoo). 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.

kettleballroll 3y ago
I don't know, I personally have a slight preference toward hg, the UI feels a bit nicer.
- mrguyorama 3y ago
  HG has an infinitely better UX than git, right up until the exact second you screwed up something and committed it to the core repo, and now you have to figure out how to undo history in a system that doesn't want you to.
aunderscored 3y ago
This kinda exists now with the newer partial clone options: https://github.blog/2020-12-21-get-up-to-speed-with-partial-clone-and-shallow-clone/ https://github.blog/2020-12-21-get-up-to-speed-with-partial-... (Edited because submitted too early :D)
- ChrisMarshallNY 3y ago
  Not sure that would work. 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.

Levitating 3y ago

Yet twenty years is also easily 1/4 of our entire lifes. We have such an incredibly short lifespan.

Jun8 3y ago

OMG, I realized while reading this that (1) I haven’t heard CVS or Subversion mentioned in a long time and (2) Spolsky probably needs an introduction at this point. Both of these point to the fact that I’m getting old! I had read somewhere that Linus coded the first version of git on an airplane ride.

rcbdev 3y ago
I know 20 year old college grads who work with Subversion in large firms - I guess Europe really is the old world in many ways.

hermitcrab 3y ago

SVN is still fine in 2024. I run a 1-man software business and see no need to take the time and effort to move to Git. I can see the benefits for a distributed team though.

wrs 3y ago

Man, I forgot all about SLM (“slime”). That thing was so awful. At one point the Windows team had to start using “merge windows” to make any progress, like the networking team gets exclusive SCM access to merge their code between 8 and noon on Tuesdays.

Veserv 3y ago

The biggest problem with git is that it is entirely a distributed version control system. In git you are always the client and the server. Your clone, normally, contains the entire history of development and all branches. In a fully distributed development model like Linux, this is a good design. 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.

moribvndvs 3y ago

20 years ago, I was using Visual Source Safe. The amount of time lost to corruptions from internal VSS bugs, deleting files forever, SMB issues (one of them being people editing files off it directly), its abysmal branching and pinning strategies, truly awful performance, etc[0]. was considerable. We tried TFS as soon as that was available, got rid of it in less than a week in favor of SVN. That was a considerable improvement until about 2010 when we got sick of constant merge headaches and poor performance and awkwardness trying to jump between branches. People slam on git a lot, but the number of incidents resulting in lost work or bad merges went from fairly routine to maybe a scant handful in the past 14 years, most of which could have been avoided by protecting mainline branches and tags from junior devs or just following good source control daily routines. [0]: https://developsense.com/visual-sourcesafe-version-control-unsafe-at-any-speed https://developsense.com/visual-sourcesafe-version-control-u...

iLemming 3y ago

What I really don't understand is why have nobody ever bothered to decentralize Pull-Requests and Issues data, just like the code sources. 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.