[bonzini]

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.

[sireat]

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/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?

[GabrielTFS]

> 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.

[resurge]

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

[2]: https://git-scm.com/docs/git-restore

[sanderjd]

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]

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.

[jon-wood]

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.

[smazga]

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".

[datavirtue]

"what the hell is git switch" --every developer

[plagiarist]

I did an alias co for checkout a while back, now I don't think I will ever unlearn that.

[erik_seaberg]

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).

[FLT8]

> 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]

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.