git is a version control framework more so than a version control system. It starts from simple primitives, exposes them to the user, then builds complex and powerful tools on top of them. Because git rebase gives you primitives to accomplish high-level tasks (e.g. "reorder these commits"), the learning experience is different because you have to learn the low-level details to accomplish your high-level task. However, because those low-level details are accessible to you, you are afforded a greater flexibility in inventing new high-level tasks.
But those high level tasks could also be exposed directly. There's nothing to stop there being more commands which more directly accomplish the desired tasks.
The idea that git is good because it is difficult to use is just "git snobbery", as is the idea that it must be difficult because it's a DVCS.
There's nothing to stop git having two levels of the API, one exposed for tools to build off of with the full complexity and another for every day use.
Git does have two levels of the API explicitly, one for tools (“plumbing”) and one for every day use (“porcelain”).
I don’t think the argument is that the difficulty is a virtue, nobody is trying to be snobby, so try to avoid jumping to that conclusion.
Git just has some inherent complexity. Git does have a steep learning curve that is the root of a UX problem. But it’s not clear what better abstractions there are or how to simplify git. Lots of people have tried to make a higher level porcelain, and the issue isn’t going away. You are welcome to suggest & create a git wrapper that makes it simpler and less dangerous.
Perforce is easier to learn, so you might try using that instead. I use both and I’m becoming more and more frustrated with Perforce because git is so much more flexible and safer and easier to use once you learn how to use git.
I totally don’t understand your implied semantic difference between “change management” and “version control”. Those sound like exactly the same thing to me. ;)
I also don’t understand your larger point about git and what the problem is. For almost everyone using git, the pushed history is sacrosanct, and the main repo is centralized. The main workflow for rebase is to clean up before making commits public.
For me "change management" is akin to IntelliJ's shelf: you can have a bunch of changes, you can combine them in lists, you can shuffle the changes between these lists and selectively apply them. Editing is the king. I should totally be able to destroy five years of my work without a way to recover.
"Version control" is a log. I should be able to return to any point in history at any time. I should not be able to destroy this history no matter what I do. The history should be backed up in a remote location.
With git every once in a while these two come into conflict: I'm using my branch as a change management system and then someone else pulls that branch and makes a couple of changes on it. Then I force push and the mess begins.
Regarding centralized repository: say, I have two working copies. In goode olde subversion there was the "master" version in trunk and two local versions, one per working copy. Three versions altogether. Pretty clear which is which.
Now in git I have:
- master in origin repo
- origin/master in wc1
- master in wc1
- actual file in wc1
- all the same in wc2
Seven potentially different versions of the same exact file.
That's even without mentioning a stash.
Rebase is a way to provide what you're calling "change management", and so is git stash. The rest of git is what you're calling "version control". I don't see any conflict. I don't love trying to differentiate those terms either, FWIW. Managing changes and controlling versions are "literally" the same thing.
> Then I force push and the mess begins.
That is your problem right there. Force pushing over published history should always be avoided. Don't do that, it is very unfriendly to others you work with. Just always pull, resolve any conflicts, then push your changes without forcing them. If you need to force in order to fix a serious mistake, then notify everyone first and have people hold their changes, then pull everything, resolve the problem, force push, and notify everyone again to "force pull" by first fetching, then reset their branch to what's in the origin verison; using reset --hard will let them avoid having any conflicts after you force pushed. Consider carefully whether the mistake even warrants a force push, or if you can make do with new commits on top that fix the bad ones.
> Regarding centralized repository [...] Seven potentially different versions of the same exact file.
You're conflating multiple different topics. The existence of multiple copies of a file isn't related to which repo is the central one, nor is it some kind of problem.
The origin repo is your central repo. Your downstream repo has to copy from the upstream/central repo if you even want to work on the code. What you called "copies" in origin/master and master are branches, not copies of the file. The only single copy on your machine from your point of view is your local workspace, which expanded from your "master". stash is something that happens behind the scenes to your git database, it's not making more working copies.
wc2 is another repo or computer, it's not even relevant. None of these copies you're talking about are visible to a user except the one working copy.
Well in either case, I'll just repeat: force push should always be avoided. Regular push without forcing can handle both of those scenarios, publishing commits to your team, and also backing up data to a safe location.
That said, making backup data in a safe location isn't what git was really made for. If you really don't want history to be there, you can use cp or rsync, or you can git clone -depth 0 from the backup machine, or just use backup software. There's "bup" which is a backup tool based on git...
This is the same argument that suggests Squarespace is better than HTML & CSS. Maybe true for some people - but not the typical HN audience, I imagine. You use git all day, every day. It's worth it to learn it inside and out, and the design assumes users who are willing to make that investment. If you assume everyone learns the primitives, then the rest of git's design makes sense as an organic evolution of that.
And for anyone who doesn't know the primitives, I posted a brief summary on Mastodon the other day:
Nah. It's a UI issue. Even when you know the primitives, the counterintuitive randomness of what is a command vs. what is a switch on a different command vs. something that can be done in three different ways using different combinations of commands and switches makes it a clusterfuck to interface with until you memorize everything. Contrast to something like mercurial where once you know the concept, you either know how to do it, or you know the command that will give you the help for how to do it. It's generally not going to be some switch on an unrelated command because the UI was actually designed and not simply cobbled together.
This isn't HTML & CSS vs squarespace, and to butcher the analogy this is more like CSS vs Sass/SCSS. CSS is the internal API which does everything but Sass is an API which exposes that in a much more beautiful way.
I don't need to know how postgres does paging, indexing, tree diffs, etc to be able to write good SQL.
I don't need to know how typescript compiles to javascript to use typescipt.
I don't need to know how my engine works to drive my car.
I use all of those every day.
But the suggestion here is that as every day users of git should learn git internals to be able to use the tool better.
That's a tooling failure. It's not a failure of the git design or git fundamentals, it's a failure of the git cli.
Mercurial's interface is just fine, and these days it's just as powerful as Git.
Things could be better. There's an existence proof. It just lost the mindshare war and so now we're stuck with Git, which I still have to look up basic syntax for because its command set is contradictory and makes no sense. (Is it git <x>? git <y> --x? git <z> <a-b>? Something else entirely? Who knows!)
I used to agree with this, now I've stopped worrying. Because if git is the worst part of your workflow, that's a great problem to have. But at many places, git is the best part.
(I've also had to work with various IBM CVS, and they are universally garbage. When I get frustrated at git, all I have to do is think back to those.)
So yes, Mercurial is better, but is it worth the effort? Not in my experience.
I know it's popular to shit on anything that isn't git these days, but you mentioned IBM CVS. I've used a couple of them, but primarily RTC (Rational Team Concert). I know that was an IBM acquisition and not a home-grown solution (what wasn't?). I personally prefer some features of RTC over how to do the equivalent in git. Namely, being able to move change sets (think commits) around freely, not having to deal with rebasing/merging into whatever branch you want to put it in/on. I also think there's something to be said for a CVS system that is built for teams that work together daily, compared to a system that's built for a "remote contributor" model.
That being said, I use git daily and find that I'm able to do everything I want and more, so I'm not looking to make a switch. Unfortunately, most people don't care to learn how to use git beyond "checkout, commit, push, call for help".
There was one before RTC, called CMVC, which was truly awful, especially using after 2010 felt like an insult to developer productivity.
I forget all the reasons why RTC isn't great, but the main one: if the server goes down, you're screwed. This happened several times, and we basically went to the pub instead of working. Slow to check out. Streams sucked compared to branches (especially when the server admin restricted creation of streams, meaning you simply could not branch at all if I'm remembering), and the capability to stash changes/switch branches to work on different work items if one was blocked was also more cumbersome. Code review was terrible.
A centralised paradigm does simplify things a lot mentally, but the workflow suffers IMO.
You certainly make some good points about the downsides of RTC. RTC's streams are often compared to git's branches because they're the closest construct, but they are definitely very different and have pretty minimal overlap, considering they're basically the parallel construct. IMO stashing changes was not bad (suspending change sets, I believe it was called), but perhaps I was mostly doing that within 1 stream and not between streams. I agree that code review was not great, though I'm not a _huge_ fan of GitHub's comment/PR review mechanism either. I'm not aware of code reviewing built in to git itself, though I could be totally missing it.
> The idea that git is good because it is difficult to use
Git is good because it is extremely elegantly designed. There are blobs, trees, commits, and refs. When you understand them, you understand pretty much everything about git.
