3 ms·

This is funny but I think it strikes at a real truth: what Git is trying to do is legitimately difficult. I can see where the author of the article is coming fr

This is funny but I think it strikes at a real truth: what Git is trying to do is legitimately difficult. I can see where the author of the article is coming from and I agree that Git has a lot of commands and it's hard to pull it all together, especially if you are new. And I agree that these commands could be better organized and presented and I think that's something the project is actively trying to address. But isn't the core idea of Git, everyone has their own repository and they share branches, kind of complicated and tricky? In my experience the developers I see having problems with Git are having trouble with the hard stuff, not the easy bits like committing and pushing a change.

Espressosaurus 6y ago
Mercurial shows that it's possible to hide much of that complexity behind a user interface that only exposes as much of that complexity as necessary. Git's--and Mercurial's--secret sauce is the directed acyclic graph of commits. Everything else is window dressing. It's complicated if you're used to a linear sequence of commits, but it's not too hard once you grasp the tree structure. All operations are operations that manipulate (or share) the DAG, so it now becomes a matter of mapping how you want to manipulate the DAG onto the command set the tool gives you. Git's toolset was designed by a dozen madmen that didn't talk to each other, so it's a loosely connected set of tools with conflicting syntax and meaning. Mercurial's toolset was designed to be used, so if you know the right terminology, you can easily figure out what command to write. Want to commit something? It's probably hg commit. Want to rebase? It's probably hg rebase. Etc. Git exposes unnecessary complexity. But it won the DVCS popularity contest, so we're stuck with it. I wish something else had won. Oh well...

Espressosaurus 6y ago

Mercurial shows that it's possible to hide much of that complexity behind a user interface that only exposes as much of that complexity as necessary. Git's--and Mercurial's--secret sauce is the directed acyclic graph of commits. Everything else is window dressing. It's complicated if you're used to a linear sequence of commits, but it's not too hard once you grasp the tree structure. All operations are operations that manipulate (or share) the DAG, so it now becomes a matter of mapping how you want to manipulate the DAG onto the command set the tool gives you. Git's toolset was designed by a dozen madmen that didn't talk to each other, so it's a loosely connected set of tools with conflicting syntax and meaning. Mercurial's toolset was designed to be used, so if you know the right terminology, you can easily figure out what command to write. Want to commit something? It's probably hg commit. Want to rebase? It's probably hg rebase. Etc. Git exposes unnecessary complexity. But it won the DVCS popularity contest, so we're stuck with it. I wish something else had won. Oh well...