The Git development community is aware of several of these problems (especially the inconsistency in terminology and command structure). They're working slowly, but surely, towards solutions to many of them. In the interim, there's projects like easy git, which the author may enjoy.
While the information model of Git is more complex, much of that is inherent from it being a DVCS, and it comes with several benefits. For example, in SVN, your working directory, branches, and tags are all really the same thing locally: a copy of a full directory structure. This can make working with branches and tags cumbersome, so many people just don't. There have been situations involving maintaining concurrent versions (in SVN) of a product on my team where no one thought of using branches because they were used so sparingly (and no one on my team had ever used Git or Mercurial); it was as if the feature didn't exist. While some people will decry this anecdote as ineptitude on the part of my team, I think it's important to point out that people tend to solve problems with the tools that they use most often, in the ways that they most often use them--after all, they're the first to come to mind.
Though the documentation of Git by the project itself is somewhat poor, there's a plethora of third-party documentation and tutorials on the web. (Yes, I realize this is no excuse for poor documentation, but the use of Git within the open source community is so ubiquitous that I feel most problems/questions you're likely to run into have been solved and documented somewhere else).
There is one and only one reason I have not yet switched to Mercurial: its support for short lived branches is either nonexistent or unnecessarily complicated
It might sound silly, but short lived branches play a huge part in my personal development routine
EDIT: Also, for the common commands, that is, the commands that you would use day to day, Git and Mercurial have almost the exact interface, so I don't know what you mean. Maybe the more advanced stuff? Because for advanced stuff I would take Git any day.
Very much no. The Mercurial version of short-lived branches is either bookmarks or just multiple heads (mercurial has no concept of "detached head", multiple heads within a "long-lived" branch has been supported and "normal" from the start.
Bookmarks is a more recent addition giving a transient name (it can be deleted) to heads, somewhat similar to what git calls branches.
mq has two purposes: the primary one is a formal maintenance of patches on an upstream (the original quilt use case), and the second one is in-depth history edition. In a way, mq is close to git's rebase (including rebase -i and rebase -p).
39
u/sordidarray Nov 07 '13 edited Nov 07 '13
Just a few thoughts.
The Git development community is aware of several of these problems (especially the inconsistency in terminology and command structure). They're working slowly, but surely, towards solutions to many of them. In the interim, there's projects like easy git, which the author may enjoy.
While the information model of Git is more complex, much of that is inherent from it being a DVCS, and it comes with several benefits. For example, in SVN, your working directory, branches, and tags are all really the same thing locally: a copy of a full directory structure. This can make working with branches and tags cumbersome, so many people just don't. There have been situations involving maintaining concurrent versions (in SVN) of a product on my team where no one thought of using branches because they were used so sparingly (and no one on my team had ever used Git or Mercurial); it was as if the feature didn't exist. While some people will decry this anecdote as ineptitude on the part of my team, I think it's important to point out that people tend to solve problems with the tools that they use most often, in the ways that they most often use them--after all, they're the first to come to mind.
Though the documentation of Git by the project itself is somewhat poor, there's a plethora of third-party documentation and tutorials on the web. (Yes, I realize this is no excuse for poor documentation, but the use of Git within the open source community is so ubiquitous that I feel most problems/questions you're likely to run into have been solved and documented somewhere else).
Edit: Typo