Okay finally RTFA and I have this to say:
> Oh, I just pushed a change. I really didn’t wanna push that, so how do I undo it?
It's always possible to reset the head back one. You "really shouldn't" because this will cause issues for anyone else downstream if they had already pulled, but this is an issue common to CVS, SVN and probably most other VCS. Arguably the Git approach is best because it actually provides a structured way to do it, and offers your downstreamers an escape hatch should they decide they don't like what you've done. As somebody else pointed out, it's like trying to unsend an email. I think you've more wiggle-room than with email though since there is a possibility to correct the record, somehow.
I'm not sure how you would do this better, a system of notifications perhaps but arguably this is something for the tools sitting atop git, and is actually "made possible" by git vs other VCS.
> How do I delete a branch? / Do you wanna delete a local branch / delete the remote tracking branch / Or delete the remote branch?
If they're coming to you it's almost certainly the remote branch, although the alternatives are so trivial they're barely worth mentioning. Most people will approach learning something new in terms of what they already know, and if they've ever used version control software before they're almost certainly thinking in terms of the old, centralised model.
> A branch is just a single concept in our head that is made complicated
I would say it is "clarified" - just like we never needed to worry about quantum effects and the classical model of physics was fine, it does one no harm to update your mental model to accomodate these things when they come to light. In a distributed setting it absolutely makes sense to be more cognisant of the split realities of two nodes in a distributed system. [0]
[0] https://en.wikipedia.org/wiki/Fallacies_of_distributed_compu...
> I have some changes. I wanna share it with Jon and Johnny so they can tell me what they think. And then maybe they can add their ideas. And then we can have a merging of our ideas, and eventually test out if it works, and have it out there and ship it.
There's a couple of things wrong with this, but the most glaring is that there are many many ways to do this first of all, but secondly it's not what git is for. It's for version control. To the extent that it supports collaboration it's still a version control tool. You can absolutely email your diffs, or put your code on a share, or do demos or exchange design documents but to me at least Git is an improvement on all of these.
> But then when we come to physically typing out all those commands… suddenly we need months or sometimes even years of learning this set of tools to become proficient enough with them.
Nobody complains about the C compiler command line? You figure out what you want, and you embed it in a Makefile or something, or you learn the commands that you need to know to do 90% of your stuff.
> I have really initially resisted the idea of graphical tools for Git, because I was this heavy terminal nerd; I was very much in my terminal bubble of being really proficient with a lot of these things,
Ah, here. Let's be clear, while I think it's important to maintain contact with the command line in these matters, you really, really need to have some good tools or you really are going to be in pain. C compiler analogy again: I can use an IDE to shield myself from these issues. The beauty of Git is it's got such widespread support there's so many great tools, and I honestly think you would be "mad" to pass them up.
> I especially see it when somebody not from my background is approaching this.
Like who? Git is a tool for managing code. I think he might be driving at non-programmers who contribute to a project like graphic designers or people providing copy. Fair enough, but that's an extension of the brief for software VCS which is primarily designed with managing and versioning text-based software ... it's not, historically what they are for. Surely there is software for managing these kinds of assets?
> I will get you to think about a directed graph or as
> No human thinks about that
I'd say a large amount of people on here think like that. All are human. But facile analysis aside, most people that use git don't talk like that or describe what they're doing like that. The "chain of commits" is a very useful mental model however.
> I’m gonna save my work and I’m gonna share it with other people. Then I’m gonna step off this computer and just leave for the day.
Yes, you can zip it up and email as an attachment, or export it on Dropbox. But when you need to store your changes "on the record" it will need to go into a version control system at some point.
> I feel that version control systems (the next version of them) should not be something that was specifically made for the Linux Kernel community
Literally any other existing version control software. Check out mercurial for something that approaches parity with git's features [1], it was an early frontrunner but Git ran away with it globally. Nobody was forced to use it, it was just the better tool.
[1] https://www.joelonsoftware.com/2010/03/17/distributed-versio...