3 ms·
I think that's a bit unfair. It presumes git is trying to abstract it's internals in the first place. It's not. Git is unapologetically a tool for manipulati
by zzalpha 10y ago
I think that's a bit unfair. It presumes git is trying to abstract it's internals in the first place.
It's not.
Git is unapologetically a tool for manipulating a DAG, and puts that right in your face.
This has pros and cons. The obvious con is that it has an immensely steep learning curve and, for users who cannot develop a mental model for how it works, forces people to rely on cargo culting.
The flipside is that it's more powerful than any SCM I've worked with, as the lack of any abstraction means you can do nearly anything you like to that DAG.
Heck, let's take this example originally posted. The remote repo has changed. Okay, well, the common case is probably to pull and... wait, merge or rebase local changes? Git gives you the choice. Other tools might not.
All that said, git could certainly be made a lot less esoteric. The command set is inconsistent and poorly named (I'm looking at you 'git reset'). And the error messages leave a lot to be desired.
As for doc, I completely disagree. I've built git training modules and my primary sources are the git docs. They're quite thorough (though they have the fault of being heavily steeped in git jargon).
- throwawayish 10y ago> They're quite thorough (though they have the fault of being heavily steeped in git jargon). So you actually agree. To understand the docs you have to understand git jargon, and the docs aren't too helpful about that. I certainly don't want to say that the git docs are bad. They're quite complete and written in mostly complete sentences, which is already pretty good as far as documentation goes. Doesn't mean that there is a lot of room for improvement.