4 ms·

I'm a big fan of Mercurial just for this reason. Mercurial offers most of the benefits of Git without the steep learning curve and poor documentation. For inst

I'm a big fan of Mercurial just for this reason. Mercurial offers most of the benefits of Git without the steep learning curve and poor documentation. For instance, git add --patch can be done with hg record.

KirinDave 19y ago
Hg misses some of the most key features. For example, most people find git's robust inline branching support to be an incredible boon for their workflow. Hg's implementation of this feature is poor by comparison.
- jmtulloss 19y ago
  Inline branching would be nice... I think they do away with this for simplicity. Inline branching doesn't make that much conceptual sense a lot of the time. That said, I wish Hg had it.
  - KirinDave 19y ago
    Forgive me, because this is not an insult, but this "doesn't make conceptual sense" argument I hear so much is so much nonsense and excuses to me. Git supports multiple workflows and allows you to either directly resolve tainted-working-copy situations directly or avoid them. By allowing for local branches you enable multiple parallel lines of development in one repository. It saves space, it saves effort, it saves time, and it's a cleaner way to organize your projects (all in one place rather than scatted across a directory listing). It also means you can evade the tainted-working-copy problem entirely by keeping short-lived, private, parallel branches of current feature development. Personally, I much prefer this mode of operation when I have the foresight to do it.
    - silentbicycle 18y ago
      Incidentally, Mercurial does this now too. (for the archives)
gcv 19y ago
I don't want to knock Mercurial; I think it's actually quite nice. However, I'm a little puzzled about why you think git has poor documentation. The User's Manual (http://www.kernel.org/pub/software/scm/git/docs/user-manual.html http://www.kernel.org/pub/software/scm/git/docs/user-manual....) is quite readable and covers most common and many uncommon use cases. I've also never had trouble making sense of the man pages for the individual commands. They are dense, but they cover a whole slew of highly advanced functionality and have always seemed to me quite thorough. Also, I'm not sure I agree git has a particularly steep learning curve. I know that in the pre-1.5 days, everyday usage required a lot more knowledge of the plumbing, but today, the high-level commands seem pretty straightforward to me. Sure, the index takes some getting used to (and a very nice tool it turns out to be, too), but is that really the only thing that makes you say that git has a steep learning curve?
orib 19y ago
Git and Mercurial are almost the same, when it comes to the command line interface! Seriously, there's a project by Carl Worth to quite literally port the Mercurial book to Git. See http://cworth.org/hgbook-git/ http://cworth.org/hgbook-git/

KirinDave 19y ago

Hg misses some of the most key features. For example, most people find git's robust inline branching support to be an incredible boon for their workflow. Hg's implementation of this feature is poor by comparison.

jmtulloss 19y ago
Inline branching would be nice... I think they do away with this for simplicity. Inline branching doesn't make that much conceptual sense a lot of the time. That said, I wish Hg had it.
- KirinDave 19y ago
  Forgive me, because this is not an insult, but this "doesn't make conceptual sense" argument I hear so much is so much nonsense and excuses to me. Git supports multiple workflows and allows you to either directly resolve tainted-working-copy situations directly or avoid them. By allowing for local branches you enable multiple parallel lines of development in one repository. It saves space, it saves effort, it saves time, and it's a cleaner way to organize your projects (all in one place rather than scatted across a directory listing). It also means you can evade the tainted-working-copy problem entirely by keeping short-lived, private, parallel branches of current feature development. Personally, I much prefer this mode of operation when I have the foresight to do it.
  - silentbicycle 18y ago
    Incidentally, Mercurial does this now too. (for the archives)

gcv 19y ago

I don't want to knock Mercurial; I think it's actually quite nice. However, I'm a little puzzled about why you think git has poor documentation. The User's Manual (http://www.kernel.org/pub/software/scm/git/docs/user-manual.html http://www.kernel.org/pub/software/scm/git/docs/user-manual....) is quite readable and covers most common and many uncommon use cases. I've also never had trouble making sense of the man pages for the individual commands. They are dense, but they cover a whole slew of highly advanced functionality and have always seemed to me quite thorough. Also, I'm not sure I agree git has a particularly steep learning curve. I know that in the pre-1.5 days, everyday usage required a lot more knowledge of the plumbing, but today, the high-level commands seem pretty straightforward to me. Sure, the index takes some getting used to (and a very nice tool it turns out to be, too), but is that really the only thing that makes you say that git has a steep learning curve?

orib 19y ago

Git and Mercurial are almost the same, when it comes to the command line interface! Seriously, there's a project by Carl Worth to quite literally port the Mercurial book to Git. See http://cworth.org/hgbook-git/ http://cworth.org/hgbook-git/