[anon35]

Made a list of all the revision control tools I've used over the decades, the year they were created, and the year I last used them:

    sccs            1973    2000
    rcs             1982    2000
    cvs             1990    2004
    clearcase       1992    2004
    perforce        1995    2011
    subversion      2000    2015
    mercurial       2005    2015
    git             2005    present

So, at least for me, they last around 15 years or so.

But often time when I tell juinors that when they're my age, git will be distant a strange memory to them, they look at me funny. It's a wonderful tool and earned its success, but I'll be sad if it's our final take on the problem.

[quietbritishjim]

In fairness, the rate of change of any type of tool slows down over time as the problem domain becomes well understood.

It's like the Joel on Software article (which annoyingly I can't find at the moment) about how software is always pretty much done by about version 4. His example was office software, especially Excel, and sure enough if you loaded Excel 4 today you'd see it does fundamentally all the main things.

I suspect we'll see git last at least double the length of time as those other VCS tools.

[eru]

I think mostly it will depend on what we will call the replacement to git. We might end up calling it 'git', too.

Less weirdly: ethernet has been replaced a few times already, but they always just end up branding the replacement as a new version of 'ethernet'.

[Shawnj2]

I do think that if there is a replacement to git in the future, it will probably have pull requests, tags, etc. built in that most git servers support but implement separately since they’re not in the standard. Alternatively, GitHub as a platform will become so standardized that they may launch their own “VCS” which is just other things bolted onto git that only work with GitHub (we’re already going there with the git command line)

[paulddraper]

> software is always pretty much done by about version 4

IPv4 has entered the chat

[rvba]

Excel has recently introduced 4-5 VERY big changes:

* javascript (arguably 'nobody' knows how to use it though, looking at the scarce resources)

* Lambdas

* Sharepoint integration, which is a type of shared notebook - and arguably this has ruined excel usability completely, since linking one file to another is basically unusable, what means were are back to the stone age, where people fucking copy paste things between files (omg)

* PowerQuery (this is not new, but seems to be the way to "fix" the problem that sharepoint files that can be edited by multiple uses are basically unusable junk)

* Updated PivotTable model that allows some basic connections between tables (this all could have been done in multiple other ways before)

For me the problem is that with the "multiplayer Excel" that seems to be promoted by Microsoft (shared workbooks on sharepoint, where multiple users can edit them at the same time), Excel lost the main functionality for actual power users, who take data from multiple source files and then consolidate them to one final report. Of course this is still "possible", but not as easy as it was before with shared drives.

I see like multiple major regressions at Microsoft that harm "average" office worker productivity now:

1) Excel file linkages broken (as described above)

2) Outlook calendar app on android -> lack of ability to have a custom notification sound (e.g. a 30 second sound), so you can skip fucking reminders, because one "ping" is easy to miss. Why cant I have a fucking calendar reminder that actually reminds me about stuff with sounds?

3) The "new" windows taskbar that combines instances of same program into one button. Do they assume that most users treat windows like a toy? Nearly every office worker has like 3-5 excel files open, 3-5 emails, maybe some PDFs - and has to switch between them. Due to the fact that taskbar is combined by default, incredible amounts od productivity are lost

4) Hibernation is hidden. So you are supposed to turn off your computer every day, then come to the office, wait for 10 minutes for it to turn on (all the antivirus, constant updates, VPN), then turn your programs back, then turn your files / emails back. So you waste another minutes to setup the computer back to work. Compare it with hibernating, where you get your work back exactly the way you left it the day before. (and yes I am aware that updates are important and so on, since they defend against zero-days, but a multi-billion dollar company has the resources to figure out how to do them without productivity loss)

5) Bonus points: your computer can wake up at 3 am to install updates and also wake you up (maybe they changed it recently, or maybe admins control this by policy)

6) Random shutdowns, because some update is so incredibly important that at least once per quarter they have to force you to turn off your computer. Bonus points are when a window pop-up "restart now" and "ok" is the selected default so you accidentally press it while typing (and yes, I do restart my computer at least once per week to get updates)

However Microsoft is no longer interested in doing any productivity studies. They dont care. Now it seems their main goal is to offshore development to low cost countries. So we get software that looks as if it was done by lowest bidder.

[bonzini]

Subversion is basically CVS done right. The problem is that CVS was a dead end that didn't scale to a distributed development model.

Git goes back to the local RCS model and adds atomic commits to that model. That's how it climbed out of the local optimum that was Subversion. There were a couple controversial choices that Git made, for example not tracking renames and not having linear revision numbers, but they turned out to be not a big deal and they allowed very efficient operations without the performance issues of e.g. darcs.

Given all the attempts to fix version control between 1995 and 2010, the basic data model of git seems to be very hard to improve on, especially with additions such as git-lfs.

There could be new command line interfaces but it has become harder and harder to kick away the incumbents. I know no one who is using git switch and git restore instead of the overloaded and confusing git checkout.

[sireat]

git-lfs is horrible, at least it was horrible the last few times I tried it out.

More precisely git-lfs is horrible the way it works with Github and its insanely low git-lfs storage and transfer limit.

What ends up happening inevitably is that you add some file to git-lfs that you did not mean to.

Only half sane/insane way to fix this is to just say screw it and start a fresh git repository, hopefully with files that you salvaged before the whole git-lfs mess.

I am quoting Github documentation "To remove Git LFS objects from a repository, delete and recreate the repository."

https://docs.github.com/en/repositories/working-with-files/m...

You say that is user error. Of course, users will make errors.

However your version control tools should get out of your way not make your life hell.

EDIT: I felt fine using Subversion combine with Redmine for issues in mid 2000s

Why did we need to go to git for everything when we still end up remoting to/from centralized hubs?

[GabrielTFS]

> I know no one who is using git switch and git restore instead of the overloaded and confusing git checkout.

Welp, I guess there's me, but it does indeed seem like adoption of the new commands hasn't been very forthcoming - I guess that's what happens when "the old way still works just fine" - but personally I'd expect that more and more people will change to the new commands over time.

[jon-wood]

I should at some point alias git checkout to throw a warning, git switch/restore are clearly a better choice, but unfortunately checkout is ingrained in muscle memory at this point.

[erik_seaberg]

I for one am trying to train myself to start using switch and restore, so that I can recommend them in company channels for people having problems with our monorepo(s).

[FLT8]

> Given all the attempts to fix version control between 1995 and 2010, the basic data model of git seems to be very hard to improve on, especially with additions such as git-lfs.

I wouldn't be surprised if some of the work and rigour being invested in OTs and CRDTs, and multi-user collaborative editing in general leads to some breakthrough improvements in the source control space too.

[sbochins]

I don’t know what we’ll be using 15 years from now. But the thing that is really sad in your list is that you stopped using mercurial in 2015, but still use git to this day.

[brmgb]

I migrated a project from clearcase to git at my first company and for all the hate I have for clearcase even I agree there was little point in switching to something else before. We had a bit of svn on other part of the company but that was it.

VCS don’t change that fast. All the tools you list before the advent of DVCS actually have a lot in common. I think git will be there for some time.

[amadeuspagel]

The internet tends to lock things in. There were many languages dominant in history at some point or another, english will be the final one. There were many scripting languages, javascript will be the final one. Many networking protocols, TCP/IP the final one. Same for git. I think the only thing that might displace git is some environment for new programmers with its own version control system like glitch[1].

[1]: https://medium.com/glitch/reinventing-version-control-with-g...

[qsantos]

> There were many scripting languages, javascript will be the final one

If, by “scripting languages”, you mean “browser-native languages”, WebAssembly might become a serious contender as the lingua franca for the Web in the long term.

[p-e-w]

> The internet tends to lock things in.

More generally, a globally connected civilization locks things in, once they are sufficiently widespread.

Barring an apocalypse, our present is eternity. I'm always amused when I read science fiction that assumes in the future, Chinese will be the lingua franca, or that we'll have political offices modeled after Ancient Rome, or that there's a world government, or similar nonsense.

To paraphrase O'Brien from 1984: "If you want a picture of the future, imagine a crony-capitalist, meme- and outrage-driven society that always seems on the brink of collapse but never actually does collapse – forever."

[test1235]

So it looks like you're ready for a change ... What's next on the horizon?

[Zacharias030]

Generally git‘s support for a stacked PR workflow is poor [0], but imho that is the future of team collab (git is great for very asynchronously built projects, like the linux kernel). I also wonder, how much better git could be if it was based on DAGs not trees (I may want to use a changeset that is still developing in more than one branch without maintaining copies of it) and corollarily I‘d like to rebase subtrees (sub-DAGs) instead of single branches.

I have introduced a stacked PR workflow to our team a while ago and a few months later half of the team had migrated to some kind of stacked PR workflow tool (on top of github and git, even though support is sub-optimal). It seems like this is an idea that is really sticky.

[0] https://github.com/ezyang/ghstack

[mattbillenstein]

Point could be made people don't really use git anymore - they use github as the primary interface. Branching, merging, review, etc.

[medstrom]

How many people know GitHub can do that? Your comment was the first I'd heard about it.

[datavirtue]

The only git GUI I use is GitLens. I have always found the command line much easier to understand...and the GUIs make me nervous.

[paulddraper]

I've never seen as the primary workflow.

It's handy, especially if you're using Git as a CMS or something like that.