3 ms·

> This is a good point. I think once developers learn Git (or as much as they need to use), then they forget how esoteric the the cli tool is. This is more up

> This is a good point. I think once developers learn Git (or as much as they need to use), then they forget how esoteric the the cli tool is. This is more up to git being horribly leaky about all it's internal implementation details. I'm not a git developer, and not even that great a user, but I know about trees and indices and refs and refspecs and packs and reachability and objects and merge drivers and smudge and clean and diamonds and countless other details that I feel should be encapsulated way better. git also has next to none documentation of these concepts.

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.

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.