The "Good news, everybody: we’re safe from Skynet!" Rant
-
@Mason_Wheeler I know SVN was free (that point is why other solutions such as TFS might not have proliferated), but point 2 is the real key here: as someone who was a holdout on SVN for years after GitHub was already hip, SVN is only really suitable if you're doing the linear move forward, multiple collaborators have all kinds of hurt unless they're very careful to not tread on each other's shoulders, and feature branching as a development model is basically impossible on SVN.
Git's capacity to merge is infinitely better than SVN's which means for projects that actual groups of people work on, it's just that much more suitable.
I cannot begin to imagine any of the stuff I've done professionally for the last 8-10 years being done on SVN because it would always end up burning everyone's time on just manually handling changes.
-
@Arantor heck, even my ADD "work on a couple parts of the project in parallel" model on my solo project would suck without feature branch/merge support.
-
@Mason_Wheeler said in The "Good news, everybody: we’re safe from Skynet!" Rant:
@Arantor 1) SVN was free too. 2) Git is good at branching and merging because branching and merging is how you do everything in Git. It's Git's "magic hammer." Before Git, we didn't do branching and merging for every little thing, because we had better ways to do them, because we weren't using Git where everything requires branching and merging!
On my previous project (same company) we used an internal-developed system called ADE. While it was inferior to SVN in some aspects (like still having per-file revision numbers) it supported a feature branch based workflow, with versioned working directories also acting like branches, and I've had git throw up merge conflicts which ade_merge would have handled itself.
-
@PleegWat said in The "Good news, everybody: we’re safe from Skynet!" Rant:
@Mason_Wheeler said in The "Good news, everybody: we’re safe from Skynet!" Rant:
@Arantor 1) SVN was free too. 2) Git is good at branching and merging because branching and merging is how you do everything in Git. It's Git's "magic hammer." Before Git, we didn't do branching and merging for every little thing, because we had better ways to do them, because we weren't using Git where everything requires branching and merging!
On my previous project (same company) we used an internal-developed system called ADE. While it was inferior to SVN in some aspects (like still having per-file revision numbers) it supported a feature branch based workflow, with versioned working directories also acting like branches, and I've had git throw up merge conflicts which ade_merge would have handled itself.
This is how the leaked manual says an ADE installation looks like:
But git is "rife with complexity"?
-
@LaoC In daily use, you request a hosted environment with an OS image which has ADE pre-installed. Yes, it has its own complexities, but those complexities serve a purpose. Like helping you work with a codebase that takes 26 hours to build, when you are actually working with a codebase that takes 26 hours to build.
-
@PleegWat the reality is that Git is like Word, it has a bazillion esoteric features, most people only use 2% of what it can do, often badly but the wizards who do need the extra features really appreciate them.
-
@apapadimoulis said in The "Good news, everybody: we’re safe from Skynet!" Rant:
world-class tools like Visual Studio
C'mon.
-
@Arantor said in The "Good news, everybody: we’re safe from Skynet!" Rant:
At least, that explains why it won out over SVN but it doesn't explain why Mercurial didn't win.
I wonder how much of Git's success is down to Github. Back when it came to be, there weren't that many good alternatives, especially for smaller private/semi-private projects. I remember everybody having their own SVN or whatever server.
Stuff like Sourceforge did exist. I think it was less shit than it is today, but IMO it was never great. It also didn't seem to have the scope of Github, where IIRC it seemed much more focused FOSS projects.
As mentioned earlier, there are tons of people for whom Git <=> Github.
Edit: From a technical point, I prefer git's ability to do local commits and edit/reorder/amend these before pushing into a central space. Git (or something like fossil) also works way better if you don't have reliable internet (e.g., while traveling).
-
@cvi for many years I had an account on repositoryhosting.com which was a cheap instance that ran SVN, Trac and associated friends, but it was never as friendly to use as GitHub.
I agree that GitHub is a large part of Git’s success, and I’d go as far as suggesting that this is partially because it has broadly-usable issues that integrate nicely with PRs, partially because it has a usable UI for browsing the repo including history.
SourceForge wasn’t entirely crap back in the day but got successively worse over time. It’s not entirely unusable at this point but compared to GitHub… GitHub wins hands down.
-
@cvi said in The "Good news, everybody: we’re safe from Skynet!" Rant:
I wonder how much of Git's success is down to Github. Back when it came to be, there weren't that many good alternatives, especially for smaller private/semi-private projects. I remember everybody having their own SVN or whatever server.
Stuff like Sourceforge did exist. I think it was less shit than it is today, but IMO it was never great. It also didn't seem to have the scope of Github, where IIRC it seemed much more focused FOSS projects.There was Google Code, which was a significantly better site than Github while it was around.
-
@Arantor said in The "Good news, everybody: we’re safe from Skynet!" Rant:
feature branching as a development model is basically impossible on SVN.
This hasn't been true for a while. It definitely used to be, but it's gotten much better about branches. It's probably still a bit behind on merging but nothing like it was.
-
@PleegWat said in The "Good news, everybody: we’re safe from Skynet!" Rant:
and I've had git throw up merge conflicts which ade_merge would have handled itself.
Yeah, that's the other thing. Git apologists' claim that Git is great at branching and merging is, like Obi-Wan Kenobi's claim that Darth Vader killed Luke's father, only true "from a certain point of view." It feels like, once again, it's been hyper-optimized for a very specific merging use case to the detriment of all else.
For example, try this:
- Project exists on two computers.
- Project contains a file with 1,000 lines of code.
- On computer A, change line 20 in this file.
- Check in changes to the repo.
- On computer B, change line 700 in this file.
- Save changes locally. Do not check in.
- Pull changes made by computer A from the repo.
SVN: Works just fine. No problem. (And why should there be?)
Git: Freaks out and declares that it's not going to even attempt to pull those changes until you either get rid of those local changes or commit them, because there might somehow mystically be a (dun dun DUNNNN!) merge conflict! (How? And if there was, what difference would having your local changes checked in make anyway?!? It would still be a merge conflict, so the entire thing is pure nonsense!)
Yeah, "doing merging well" is easy if you dump all the complexity on the end user and refuse to play the merge game on anything other than easy mode!
-
@Mason_Wheeler said in The "Good news, everybody: we’re safe from Skynet!" Rant:
@PleegWat said in The "Good news, everybody: we’re safe from Skynet!" Rant:
and I've had git throw up merge conflicts which ade_merge would have handled itself.
Yeah, that's the other thing. Git apologists' claim that Git is great at branching and merging is, like Obi-Wan Kenobi's claim that Darth Vader killed Luke's father, only true "from a certain point of view." It feels like, once again, it's been hyper-optimized for a very specific merging use case to the detriment of all else.
For example, try this:
- Project exists on two computers.
- Project contains a file with 1,000 lines of code.
- On computer A, change line 20 in this file.
- Check in changes to the repo.
- On computer B, change line 700 in this file.
- Save changes locally. Do not check in.
- Pull changes made by computer A from the repo.
SVN: Works just fine. No problem. (And why should there be?)
Git: Freaks out and declares that it's not going to even attempt to pull those changes until you either get rid of those local changes or commit them, because there might somehow mystically be a (dun dun DUNNNN!) merge conflict! (How? And if there was, what difference would having your local changes checked in make anyway?!? It would still be a merge conflict, so the entire thing is pure nonsense!)
Yeah, "doing merging well" is easy if you dump all the complexity on the end user and refuse to play the merge game on anything other than easy mode!
This is actually a major failure of svn (I say as someone who still uses it daily). We've had this argument before.
You really don't want automated merging of stuff you can't revert. Anyways, I don't. You're welcome to risk your work in progress.
-
@boomzilla Yes, and 6 years later, your argument remains nonsensical. You immediately 'd to actual merge conflicts, which is not what was being discussed, and somehow I got distracted and missed that the first time around.
If two entirely different portions of a file get changed, and the changes are integrated, there is no possibility of a merge conflict. None. Zero. Does not and can not exist. It is possible that this could introduce logical problems in the code at the language level, such as if your local changes renamed or deleted a field that the remote code relies upon, but 1) that's not a merge conflict and it's not an issue that it's possible for the VCS to comprehend, and 2) the same logical problem would be introduced regardless, even if your local changes were checked in, so what benefit comes from checking them in to avoid the nonexistent merge conflict?
-
You have a very different experience of SVN than I did while using it daily. My experiences are from 10+ years ago, and I will treat them as valid as such because that was absolutely part of why I moved to Git at the time.
I see no reason to switch back now though.
-
@Mason_Wheeler said in The "Good news, everybody: we’re safe from Skynet!" Rant:
@boomzilla Yes, and 6 years later, your argument remains nonsensical. You immediately 'd to actual merge conflicts, which is not what was being discussed, and somehow I got distracted and missed that the first time around.
If two entirely different portions of a file get changed, and the changes are integrated, there is no possibility of a merge conflict. None. Zero. Does not and can not exist. It is possible that this could introduce logical problems in the code at the language level, such as if your local changes renamed or deleted a field that the remote code relies upon, but 1) that's not a merge conflict and it's not an issue that it's possible for the VCS to comprehend, and 2) the same logical problem would be introduced regardless, even if your local changes were checked in, so what benefit comes from checking them in to avoid the nonexistent merge conflict?
I don't care about this weird fixation on the words "merge conflicts." It's just a problem with the way svn works that others don't have. Attempting to merge uncommitted changes is dangerous and you shouldn't do it. Because you don't have the committed version to start over with if you decide the merge didn't work.
Why do you bother with version control at all if that's your attitude?
-
@boomzilla Because the "danger" remains purely hypothetical. Real problems exist in reality, and neither then nor now did you present a reproducible scenario in which this causes real problems. Which is what I opened with, so that anyone can reproduce the actual problem and see it for themselves. If you refuse to do literally the most basic thing to demonstrate the issue, all the rest of us are fully justified in refusing to believe the issue is real.
-
@Mason_Wheeler said in The "Good news, everybody: we’re safe from Skynet!" Rant:
@boomzilla Because the "danger" remains purely hypothetical.
You cannot be serious.
Real problems exist in reality, and neither then nor now did you present a reproducible scenario in which this causes real problems. Which is what I opened with, so that anyone can reproduce the actual problem and see it for themselves. If you refuse to do literally the most basic thing to demonstrate the issue, all the rest of us are fully justified in refusing to believe the issue is real.
I wrote under the (known bad, due to posting history) assumption you were smart enough to understand the concept of files being changed and the understanding of what it means to have versions committed or not.
You even admitted that "logical problems" were possible, which speaks well to you having actual experience working with actual code, so you're actually agreeing with me, no matter how much you continue protest otherwise.
-
Besides, there's no need to commit your local changes as a proper commit, you can just stash them.
I remember SVN:s automatic merges creating a huge mess. It wasn't common - it probably worked 99% or something of the times just fine - but the times when it silently made a mess, it wasn't pretty.
-
@cvi said in The "Good news, everybody: we’re safe from Skynet!" Rant:
Besides, there's no need to commit your local changes as a proper commit, you can just stash them.
I remember SVN:s automatic merges creating a huge mess. It wasn't common - it probably worked 99% or something of the times just fine - but the times when it silently made a mess, it wasn't pretty.
I remember having to fix broken SVN repos several times in a year. Holy hell did I curse it over and over. And then I had ClearCase inflicted on me. I'm still not quite over that particular pile of shit. Oh, you want to back out of a partial merge? Nope! Write your own god damned shell script to nuke commits manually and hope that everything is still fine after.
Sheez, that was not a fun day.
-
@boomzilla said in The "Good news, everybody: we’re safe from Skynet!" Rant:
@Mason_Wheeler said in The "Good news, everybody: we’re safe from Skynet!" Rant:
@boomzilla Because the "danger" remains purely hypothetical.
You cannot be serious.
Real problems exist in reality, and neither then nor now did you present a reproducible scenario in which this causes real problems. Which is what I opened with, so that anyone can reproduce the actual problem and see it for themselves. If you refuse to do literally the most basic thing to demonstrate the issue, all the rest of us are fully justified in refusing to believe the issue is real.
I wrote under the (known bad, due to posting history) assumption you were smart enough to understand the concept of files being changed and the understanding of what it means to have versions committed or not.
"Committed." Remember that you can't push any changes until after the merge, so all you have is a local commit.
You even admitted that "logical problems" were possible, which speaks well to you having actual experience working with actual code, so you're actually agreeing with me, no matter how much you continue protest otherwise.
Now don't start with that nonsense again. We both agree on the obvious: that logical problems can exist. You haven't established how Git's refusal to handle uncommitted changes has any relevance to resolving that problem in a better way. (Especially since the standard way of dealing with this scenario, officially recommended in the UI by both the Git CLI client and the Github Desktop client, is not to make a local commit of your changes at all, but rather to shelve -> pull -> unshelve, so that local-commit-as-rollback-point you're lauding the benefits of doesn't ever exist in the first place!)
-
@Mason_Wheeler said in The "Good news, everybody: we’re safe from Skynet!" Rant:
There was Google Code, which was a significantly better site than Github while it was around.
But Github got better... and Google Code got shut down, yet another victim of Google's toxic internal culture.
-
@Mason_Wheeler said in The "Good news, everybody: we’re safe from Skynet!" Rant:
@boomzilla said in The "Good news, everybody: we’re safe from Skynet!" Rant:
@Mason_Wheeler said in The "Good news, everybody: we’re safe from Skynet!" Rant:
@boomzilla Because the "danger" remains purely hypothetical.
You cannot be serious.
Real problems exist in reality, and neither then nor now did you present a reproducible scenario in which this causes real problems. Which is what I opened with, so that anyone can reproduce the actual problem and see it for themselves. If you refuse to do literally the most basic thing to demonstrate the issue, all the rest of us are fully justified in refusing to believe the issue is real.
I wrote under the (known bad, due to posting history) assumption you were smart enough to understand the concept of files being changed and the understanding of what it means to have versions committed or not.
"Committed." Remember that you can't push any changes until after the merge, so all you have is a local commit.
Yes. What's with the eye roll?
You even admitted that "logical problems" were possible, which speaks well to you having actual experience working with actual code, so you're actually agreeing with me, no matter how much you continue protest otherwise.
Now don't start with that nonsense again. We both agree on the obvious: that logical problems can exist. You haven't established how Git's refusal to handle uncommitted changes has any relevance to resolving that problem in a better way. (Especially since the standard way of dealing with this scenario, officially recommended in the UI by both the Git CLI client and the Github Desktop client, is not to make a local commit of your changes at all, but rather to shelve -> pull -> unshelve, so that local-commit-as-rollback-point you're lauding the benefits of doesn't ever exist in the first place!)
The point is that you have the state stored in a useful way. In a way that you absolutely don't with svn. Again, you're obsessed with irrelevant labels.
-
@Mason_Wheeler said in The "Good news, everybody: we’re safe from Skynet!" Rant:
"Committed." Remember that you can't push any changes until after the merge, so all you have is a local commit.
What's less "real" about it than any other commit?
-
@LaoC Your code is not "committed to version control" in any meaningful way until it has a bus factor >1. When all you have is a local commit, you've got nothing, because if your hard drive dies, the changes die with it, exactly the same as if you had not made a local commit at all.
-
@Mason_Wheeler said in The "Good news, everybody: we’re safe from Skynet!" Rant:
You haven't established how Git's refusal to handle uncommitted changes has any relevance to resolving that problem in a better way.
Local commits are cheap. Very very cheap. And you can reset to throw them away.
The result of this is that when you have a conflict, you can resolve it more on your own time; it's not a stop-the-world-disaster event. In the easy case, you just rebase your diverged branch on the remote branch and try to push again. (You may need to resolve merge conflicts while doing this.) It's not a big deal... unless everyone is all working on a primary branch in some sort of monorepo, and that's a workflow model that git doesn't encourage (and Github really doesn't encourage).
-
@Mason_Wheeler said in The "Good news, everybody: we’re safe from Skynet!" Rant:
@LaoC Your code is not "committed to version control" in any meaningful way until it has a bus factor >1. When all you have is a local commit, you've got nothing, because if your hard drive dies, the changes die with it, exactly the same as if you had not made a local commit at all.
version control != backup
Edit: this would mean
rcs
wasn't version control to begin with.
-
@Mason_Wheeler said in The "Good news, everybody: we’re safe from Skynet!" Rant:
When all you have is a local commit, you've got nothing
No, you have a local commit. You perhaps should be pushing it elsewhere, of course, but you still have it. You can switch to another branch and then switch back and it will still be there under normal circumstances. You still have it in your local history. It's not getting lost.
Drives mostly don't die. You may have noticed this. Or rather a dying drive is pretty noticeable.
-
@LaoC said in The "Good news, everybody: we’re safe from Skynet!" Rant:
@Mason_Wheeler said in The "Good news, everybody: we’re safe from Skynet!" Rant:
@LaoC Your code is not "committed to version control" in any meaningful way until it has a bus factor >1. When all you have is a local commit, you've got nothing, because if your hard drive dies, the changes die with it, exactly the same as if you had not made a local commit at all.
version control != backup
Yes, that's precisely what version control is: a versioned, integrated backup. If it's not versioned, integrated, or backed up, it's not version control.
-
@Mason_Wheeler said in The "Good news, everybody: we’re safe from Skynet!" Rant:
Yes, that's precisely what version control is: a versioned, integrated backup.
It's history, not a backup.
-
@dkf said in The "Good news, everybody: we’re safe from Skynet!" Rant:
@Mason_Wheeler said in The "Good news, everybody: we’re safe from Skynet!" Rant:
Yes, that's precisely what version control is: a versioned, integrated backup.
It's history, not a backup.
That's the "versioned" part.
-
@Mason_Wheeler said in The "Good news, everybody: we’re safe from Skynet!" Rant:
@LaoC Your code is not "committed to version control" in any meaningful way until it has a bus factor >1.
This is super stupid. Do you also not bother to save files locally and edit them on the VCS server for great meaning?
-
-
-
@boomzilla Exactly what? That makes no sense.
-
@dkf said in The "Good news, everybody: we’re safe from Skynet!" Rant:
Drives mostly don't die. You may have noticed this. Or rather a dying drive is pretty noticeable.
Fine. If your computer dies catastrophically, same deal. Or if it gets stolen. Yes, these are rare events, but they do happen and they're the reason why you keep backups of your code.
-
@Mason_Wheeler But it's not a backup, because a backup necessarily involves separate storage. The history part is the important bit of any VCS; you don't just have the current configuration, but you have all the other ones in the past as well.
The VCS may be replicated elsewhere. That makes it more backup-like (though with different integrity requirements; there's a few other differences).
-
@Mason_Wheeler said in The "Good news, everybody: we’re safe from Skynet!" Rant:
@dkf said in The "Good news, everybody: we’re safe from Skynet!" Rant:
Drives mostly don't die. You may have noticed this. Or rather a dying drive is pretty noticeable.
Fine. If your computer dies catastrophically, same deal. Or if it gets stolen. Yes, these are rare events, but they do happen and they're the reason why you keep backups of your code.
What happens if your SVN server dies catastrophically? What happens if a meteor hits your backup storage server?
Bah, this is all too deep into the category of dumb what-ifs.
-
@dkf said in The "Good news, everybody: we’re safe from Skynet!" Rant:
@Mason_Wheeler But it's not a backup, because a backup necessarily involves separate storage. The history part is the important bit of any VCS; you don't just have the current configuration, but you have all the other ones in the past as well.
I disagree. All three components of the definition of version control I gave above (versioned, integrated, backed up) are crucial. Take away any one of the three and you don't have a VCS worth using. (Theoretically you could get away with dropping integration if you're a solo dev working on a project alone, but then you'd have a toy VCS in much the same way as SQLite is a toy pretending to be a real database.)
-
@Mason_Wheeler said in The "Good news, everybody: we’re safe from Skynet!" Rant:
@boomzilla Exactly what? That makes no sense.
Yes, you're being super retarded and I reflected your thoughts back at you. In what way is a local commit meaningless? You're correct that it doesn't do any good for the rest of the project until it gets there but the point is that it's still something you're working on, and pretty much all changes start that way before making it to the central repository.
-
@Carnage said in The "Good news, everybody: we’re safe from Skynet!" Rant:
I had ClearCase inflicted on me.
Which heinous crime did you commit to warrant such a punishment?
-
@Mason_Wheeler said in The "Good news, everybody: we’re safe from Skynet!" Rant:
@dkf said in The "Good news, everybody: we’re safe from Skynet!" Rant:
@Mason_Wheeler But it's not a backup, because a backup necessarily involves separate storage. The history part is the important bit of any VCS; you don't just have the current configuration, but you have all the other ones in the past as well.
I disagree. All three components of the definition of version control I gave above (versioned, integrated, backed up) are crucial. Take away any one of the three and you don't have a VCS worth using. (Theoretically you could get away with dropping integration if you're a solo dev working on a project alone, but then you'd have a toy VCS in much the same way as SQLite is a toy pretending to be a real database.)
Yes, but this is all some stupid hallucination of yours where you object to having a repeatable state from which to merge incoming changes.
-
@boomzilla said in The "Good news, everybody: we’re safe from Skynet!" Rant:
@Mason_Wheeler said in The "Good news, everybody: we’re safe from Skynet!" Rant:
@boomzilla Exactly what? That makes no sense.
Yes, you're being super retarded and I reflected your thoughts back at you. In what way is a local commit meaningless?
In the sense that either your code is ready to be committed to the repo or it isn't. In my entire career I've never seen a valid in-between state.
-
@Mason_Wheeler someone should show you Gerrit sometime.
-
@Arantor said in The "Good news, everybody: we’re safe from Skynet!" Rant:
@Mason_Wheeler someone should show you Gerrit sometime.
-
@Zerosquare said in The "Good news, everybody: we’re safe from Skynet!" Rant:
@Carnage said in The "Good news, everybody: we’re safe from Skynet!" Rant:
I had ClearCase inflicted on me.
Which heinous crime did you commit to warrant such a punishment?
I became a programmer.
-
@Carnage said in The "Good news, everybody: we’re safe from Skynet!" Rant:
I became a programmer.
-
@Mason_Wheeler said in The "Good news, everybody: we’re safe from Skynet!" Rant:
@boomzilla said in The "Good news, everybody: we’re safe from Skynet!" Rant:
@Mason_Wheeler said in The "Good news, everybody: we’re safe from Skynet!" Rant:
@boomzilla Exactly what? That makes no sense.
Yes, you're being super retarded and I reflected your thoughts back at you. In what way is a local commit meaningless?
In the sense that either your code is ready to be committed to the repo or it isn't. In my entire career I've never seen a valid in-between state.
And so in this mission of black and white you've short circuited your brain when it comes to merging incoming changes with what you're working on.
-
@Mason_Wheeler said in The "Good news, everybody: we’re safe from Skynet!" Rant:
@Arantor said in The "Good news, everybody: we’re safe from Skynet!" Rant:
@Mason_Wheeler someone should show you Gerrit sometime.
It’s a Git server where you can save draft commits, and revise the drafts until you have each commit be perfect whereupon the final perfect commit (or even a branch full of them) hits the actual repository.
Yo dawg I herd u liek versioned history so imma version control your version control.
-
@Mason_Wheeler said in The "Good news, everybody: we’re safe from Skynet!" Rant:
@dkf said in The "Good news, everybody: we’re safe from Skynet!" Rant:
@Mason_Wheeler But it's not a backup, because a backup necessarily involves separate storage. The history part is the important bit of any VCS; you don't just have the current configuration, but you have all the other ones in the past as well.
I disagree. All three components of the definition of version control I gave above (versioned, integrated, backed up) are crucial. Take away any one of the three and you don't have a VCS worth using. (Theoretically you could get away with dropping integration if you're a solo dev working on a project alone, but then you'd have a toy VCS in much the same way as SQLite is a toy pretending to be a real database.)
So,s ay you have SVN, when SVN gets unrestorably corrupted, how do you restore that SVN to a workings state using itself? Backup is separate from VCS. Distributed VCSes get a sorta, kinda, backup feature by means of mildly modified copies existing everywhere, but they are not a replacement for backups.