The only thing that I can see ever replace git is something that is fully backwards compatible with git and insanely intuitive and possibly extents git or replaces it, but again key thing would be 100% support for regular git repositories, if people enjoy using it with existing git codebases thats step 1. Im not sure if anybody is even trying to engineer such a thing, and lets say they have 100% backwards compatibility with git, what would you change about it to migrate into? Do you keep the same exact underlying git but the commands are more ergonomic somehow? Or are there alternative approaches to how git stores code that could be more efficient somehow?
It takes someone making something better but also compatible with the dominant offering.
Sidenote I had a coworker who worked with people using SVN but he kept a git branch still so he could more easily revert code and experiment, I forget his approach but it seemed to work. I assume the repo from git was a layer above the SVN directory maybe. This goes back to what I am saying though, even though its a little different he was able to still satisfy the needs of the client with their tooling but still use tooling that hes productive on.
You can drop it in and work seamlessly from git repos
(And it's totally possible GitHub will still be there in 20 years - we're still all using Windows and macOS and Unix, aren't we?)
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.
Or it'll all just be done by LLMs then.
It'll be interesting to see if this plays out, or if git (and github) have reached some sort of local maximum in VCS where it does enough for most people that there's not much benefit to moving to a new tool.
Of course there might be some massive leap in VCS technology, but it'd be hard to predict.