Guessing you aren’t working with hundreds of collaborators in a distributed offline system. Which is what git was for and why svn wasn’t enough for that type of use case.
The vast majority of git users are using github as a central repository. There a a few other not github but serves the same purpose central repositories. Distributed sounds cool, but almost everybody wouldn't notice a thing if git was centralized.
Yup, I guess local commits when GitHub is offline (as it is frequently) is a decent improvement on a central subversion server if you are genuinely working offline or your scan server is as faliable as saas tends to be.
I used subversion for 10 years and don’t ever recall a problem when it was offline but the killed feature of GitHub - distributed source control - proved too complex
For the majority of development teams. Instead there’s a “main” which people fork, add a feature, then merge and delete the fork.
for me atomic commit or was that committing a bunch of files with 1 command was important. and cvs wouldnt let me do it. perforce did. but it was proprietary software, though i think they offered a free version for solo developers or something like that. and when svn came out i jumped ship.
I came here to say precisely that. I was on svn before git was a thing, and I've never moved off it for any projects where I get to decide such things.
To a first approximation, one could say that distributed version control is a problem nobody ever had, and nobody ever intends to have. (GitHub is the world's centralized monorepo.)
Yet, distributed version control is the majority of the reason why git's mental model is so overcomplicated.
> To a first approximation, one could say that distributed version control is a problem nobody ever had, and nobody ever intends to have.
The distributed aspect is important because it let me separate how I’d like to control changes vs how it’s done in the canonical repo. I sync when I want to.
Guessing you aren’t working with hundreds of collaborators in a distributed offline system. Which is what git was for and why svn wasn’t enough for that type of use case.
The vast majority of git users are using github as a central repository. There a a few other not github but serves the same purpose central repositories. Distributed sounds cool, but almost everybody wouldn't notice a thing if git was centralized.
Yup, I guess local commits when GitHub is offline (as it is frequently) is a decent improvement on a central subversion server if you are genuinely working offline or your scan server is as faliable as saas tends to be.
I used subversion for 10 years and don’t ever recall a problem when it was offline but the killed feature of GitHub - distributed source control - proved too complex For the majority of development teams. Instead there’s a “main” which people fork, add a feature, then merge and delete the fork.
u guessed right. im one of the world's few solo software developers left (behind).
Keep on keeping on brother.
1 reply →
or using branches.
oh svn had branches. people just didn't know that they wanted a distributed cvs.
for me atomic commit or was that committing a bunch of files with 1 command was important. and cvs wouldnt let me do it. perforce did. but it was proprietary software, though i think they offered a free version for solo developers or something like that. and when svn came out i jumped ship.
> i am actually fine with how svn works.
I came here to say precisely that. I was on svn before git was a thing, and I've never moved off it for any projects where I get to decide such things.
To a first approximation, one could say that distributed version control is a problem nobody ever had, and nobody ever intends to have. (GitHub is the world's centralized monorepo.)
Yet, distributed version control is the majority of the reason why git's mental model is so overcomplicated.
Well, one person did: git exactly replicated the patch email system that Linus Torvalds was using.
> To a first approximation, one could say that distributed version control is a problem nobody ever had, and nobody ever intends to have.
The distributed aspect is important because it let me separate how I’d like to control changes vs how it’s done in the canonical repo. I sync when I want to.