4 ms·

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 contro

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.
- seanc 3y ago
  Git-svn is very mature and feature rich. I've used it a couple of times to good effect. Little need for it these days though. https://git-scm.com/docs/git-svn https://git-scm.com/docs/git-svn
  - burstmode 3y ago
    I want the reverse: svn-git. That would be a real relief to so many developers.
    - seanc 3y ago
      Er, git-svn is bi-directional? Targeted at allowing a developer to have a local git workflow that syncs up nicely with a central svn server? Is that the svn-git you're after?
      - burstmode 3y ago
        No, the exact reverse: Hide away the brain-damaging GIT database system behind a proxy, so that I can (again!) concentrate on my job as developer. Instead I have to spend at least one day every week as "version managment administrator" just to keep GIT from falling apart because of weird internal errors. I will never understand why a plain user must deal with internal data structures (like db-indieces) of some tool on a day to day basis.
  - giancarlostoro 3y ago
    I'm not sure if he used this or not, I just know he had both an SVN repo (went to client) and a git repo (for himself).
- dminor 3y ago
  Jujutsu is along the lines of what you describe: https://github.com/martinvonz/jj https://github.com/martinvonz/jj You can drop it in and work seamlessly from git repos
GardenLetter27 3y ago
Probably VCS based on ASTs instead of text changes directly. Or it'll all just be done by LLMs then.
thenoblesunfish 3y ago
A good reason to try to rely only on the things that are "Git" as opposed to "GitHub"! (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?)
remus 3y ago
> It is sobering to realize that in twenty years, Github will probably be gone, and no one will be using Git anymore. 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.

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.

seanc 3y ago
Git-svn is very mature and feature rich. I've used it a couple of times to good effect. Little need for it these days though. https://git-scm.com/docs/git-svn https://git-scm.com/docs/git-svn
- burstmode 3y ago
  I want the reverse: svn-git. That would be a real relief to so many developers.
  - seanc 3y ago
    Er, git-svn is bi-directional? Targeted at allowing a developer to have a local git workflow that syncs up nicely with a central svn server? Is that the svn-git you're after?
    - burstmode 3y ago
      No, the exact reverse: Hide away the brain-damaging GIT database system behind a proxy, so that I can (again!) concentrate on my job as developer. Instead I have to spend at least one day every week as "version managment administrator" just to keep GIT from falling apart because of weird internal errors. I will never understand why a plain user must deal with internal data structures (like db-indieces) of some tool on a day to day basis.
- giancarlostoro 3y ago
  I'm not sure if he used this or not, I just know he had both an SVN repo (went to client) and a git repo (for himself).
dminor 3y ago
Jujutsu is along the lines of what you describe: https://github.com/martinvonz/jj https://github.com/martinvonz/jj You can drop it in and work seamlessly from git repos

GardenLetter27 3y ago

Probably VCS based on ASTs instead of text changes directly. Or it'll all just be done by LLMs then.

thenoblesunfish 3y ago

A good reason to try to rely only on the things that are "Git" as opposed to "GitHub"! (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?)

remus 3y ago

> It is sobering to realize that in twenty years, Github will probably be gone, and no one will be using Git anymore. 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.