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.

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