3 ms·

Subversion is basically CVS done right. The problem is that CVS was a dead end that didn't scale to a distributed development model. Git goes back to the local

Subversion is basically CVS done right. The problem is that CVS was a dead end that didn't scale to a distributed development model. Git goes back to the local RCS model and adds atomic commits to that model. That's how it climbed out of the local optimum that was Subversion. There were a couple controversial choices that Git made, for example not tracking renames and not having linear revision numbers, but they turned out to be not a big deal and they allowed very efficient operations without the performance issues of e.g. darcs. Given all the attempts to fix version control between 1995 and 2010, the basic data model of git seems to be very hard to improve on, especially with additions such as git-lfs. There could be new command line interfaces but it has become harder and harder to kick away the incumbents. I know no one who is using git switch and git restore instead of the overloaded and confusing git checkout.

FLT8 3y ago
> Given all the attempts to fix version control between 1995 and 2010, the basic data model of git seems to be very hard to improve on, especially with additions such as git-lfs. I wouldn't be surprised if some of the work and rigour being invested in OTs and CRDTs, and multi-user collaborative editing in general leads to some breakthrough improvements in the source control space too.
- llwu 3y ago
  Aren't CRDTs the logical conclusion of automatic merging? I feel like with source control you want to be more intentional about what gets merged, right? Maybe CRDT can be good for trunk-based development with a merge queue. Definitely has a spot in pair programming.
GabrielTFS 3y ago
> I know no one who is using git switch and git restore instead of the overloaded and confusing git checkout. Welp, I guess there's me, but it does indeed seem like adoption of the new commands hasn't been very forthcoming - I guess that's what happens when "the old way still works just fine" - but personally I'd expect that more and more people will change to the new commands over time.
- sanderjd 3y ago
  It makes sense for old timers to keep just doing it the way we always have, but I wonder how newcomers to version control are being taught. I would really hope they aren't just being thrown a bunch of these inscrutable commands by their leads, like when I learned it!
  - htfu 3y ago
    Judging by my colleagues (whether more or less experienced than me), "whatever the GUI allows for". Yes, almost the entire company runs on the subset of git presented by Visual Studio and Azure DevOps. I would guess this is more and more common, and even the more obvious shortcuts available for many things through git itself will become more and more arcane.
- resurge 3y ago
  I just checked these commands out to update my git knowledge, but when I saw the following in the docs [1][2] I immediately marked these commands as not (yet) worth it to learn since the way these commands work might change. THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE. So that might have something to do with it as well. Especially if there are stable commands that I already know that have the same functionality. [1]: https://git-scm.com/docs/git-switch https://git-scm.com/docs/git-switch [2]: https://git-scm.com/docs/git-restore https://git-scm.com/docs/git-restore
erik_seaberg 3y ago
I for one am trying to train myself to start using switch and restore, so that I can recommend them in company channels for people having problems with our monorepo(s).
jon-wood 3y ago
I should at some point alias git checkout to throw a warning, git switch/restore are clearly a better choice, but unfortunately checkout is ingrained in muscle memory at this point.
- datavirtue 3y ago
  "what the hell is git switch" --every developer
- plagiarist 3y ago
  I did an alias co for checkout a while back, now I don't think I will ever unlearn that.
- smazga 3y ago
  I, personally, would find this very helpful if git did it by default. I learned git by searching for "how do I?" stuff. Now I know how to do things, so I don’t go looking. It's possible that there are new and improved workflows, but I'll never know because it already works for me, even if I do it "the hard way".
sireat 3y ago
git-lfs is horrible, at least it was horrible the last few times I tried it out. More precisely git-lfs is horrible the way it works with Github and its insanely low git-lfs storage and transfer limit. What ends up happening inevitably is that you add some file to git-lfs that you did not mean to. Only half sane/insane way to fix this is to just say screw it and start a fresh git repository, hopefully with files that you salvaged before the whole git-lfs mess. I am quoting Github documentation "To remove Git LFS objects from a repository, delete and recreate the repository." https://docs.github.com/en/repositories/working-with-files/managing-large-files/removing-files-from-git-large-file-storage https://docs.github.com/en/repositories/working-with-files/m... You say that is user error. Of course, users will make errors. However your version control tools should get out of your way not make your life hell. EDIT: I felt fine using Subversion combine with Redmine for issues in mid 2000s Why did we need to go to git for everything when we still end up remoting to/from centralized hubs?

FLT8 3y ago

> Given all the attempts to fix version control between 1995 and 2010, the basic data model of git seems to be very hard to improve on, especially with additions such as git-lfs. I wouldn't be surprised if some of the work and rigour being invested in OTs and CRDTs, and multi-user collaborative editing in general leads to some breakthrough improvements in the source control space too.

llwu 3y ago
Aren't CRDTs the logical conclusion of automatic merging? I feel like with source control you want to be more intentional about what gets merged, right? Maybe CRDT can be good for trunk-based development with a merge queue. Definitely has a spot in pair programming.

GabrielTFS 3y ago

> I know no one who is using git switch and git restore instead of the overloaded and confusing git checkout. Welp, I guess there's me, but it does indeed seem like adoption of the new commands hasn't been very forthcoming - I guess that's what happens when "the old way still works just fine" - but personally I'd expect that more and more people will change to the new commands over time.

sanderjd 3y ago
It makes sense for old timers to keep just doing it the way we always have, but I wonder how newcomers to version control are being taught. I would really hope they aren't just being thrown a bunch of these inscrutable commands by their leads, like when I learned it!
- htfu 3y ago
  Judging by my colleagues (whether more or less experienced than me), "whatever the GUI allows for". Yes, almost the entire company runs on the subset of git presented by Visual Studio and Azure DevOps. I would guess this is more and more common, and even the more obvious shortcuts available for many things through git itself will become more and more arcane.
resurge 3y ago
I just checked these commands out to update my git knowledge, but when I saw the following in the docs [1][2] I immediately marked these commands as not (yet) worth it to learn since the way these commands work might change. THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE. So that might have something to do with it as well. Especially if there are stable commands that I already know that have the same functionality. [1]: https://git-scm.com/docs/git-switch https://git-scm.com/docs/git-switch [2]: https://git-scm.com/docs/git-restore https://git-scm.com/docs/git-restore

erik_seaberg 3y ago

I for one am trying to train myself to start using switch and restore, so that I can recommend them in company channels for people having problems with our monorepo(s).

jon-wood 3y ago

I should at some point alias git checkout to throw a warning, git switch/restore are clearly a better choice, but unfortunately checkout is ingrained in muscle memory at this point.

datavirtue 3y ago
"what the hell is git switch" --every developer
plagiarist 3y ago
I did an alias co for checkout a while back, now I don't think I will ever unlearn that.
smazga 3y ago
I, personally, would find this very helpful if git did it by default. I learned git by searching for "how do I?" stuff. Now I know how to do things, so I don’t go looking. It's possible that there are new and improved workflows, but I'll never know because it already works for me, even if I do it "the hard way".

sireat 3y ago

git-lfs is horrible, at least it was horrible the last few times I tried it out. More precisely git-lfs is horrible the way it works with Github and its insanely low git-lfs storage and transfer limit. What ends up happening inevitably is that you add some file to git-lfs that you did not mean to. Only half sane/insane way to fix this is to just say screw it and start a fresh git repository, hopefully with files that you salvaged before the whole git-lfs mess. I am quoting Github documentation "To remove Git LFS objects from a repository, delete and recreate the repository." https://docs.github.com/en/repositories/working-with-files/managing-large-files/removing-files-from-git-large-file-storage https://docs.github.com/en/repositories/working-with-files/m... You say that is user error. Of course, users will make errors. However your version control tools should get out of your way not make your life hell. EDIT: I felt fine using Subversion combine with Redmine for issues in mid 2000s Why did we need to go to git for everything when we still end up remoting to/from centralized hubs?