|
|
|
|
|
by Grue3
3545 days ago
|
|
Hg has a lot of problems. It has bookmarks AND branches (for some reason). To edit your commit history you need to pray to the elder gods and sacrifice a newborn. I consider myself pretty smart and yet my mind went completely blank every time I read about anything related to Mercurial Queues. The default install lacks too many features, you need to enable extensions to do even the most basic stuff, like stashing. Darcs is obviously better than git, but very few people know it exists. And none of free web repositories support it. |
|
That said, my main issue is that git is a good set of primitives for file change management. But its main design principles are not about SCM. It sacrifices ease of workflow for source control, in favor of making centralized maintainer worflows simpler. This is a perfectly fine trade off for a system largely optimized for a few linux kernel maintainers, dealing with lots of distributed and unorganized contributors (frequently over email).
Those same workflows are not necessarily the best way to organize a small (tens of developers) team with a linear history product.
Some time try to onboard a new-grad developer to a team like the former. You spend way more time explaining git internals and data structures than you do source control management. This just isn't true if you do the same thing with other source control systems. Its easier to explain TFS, SVN, hg, perforce or accurev (the systems I have actual working experience with) in every instance.
My opinion is, if bitbucket and github had switched business models early on (ie hg repos for free if they were public and git repos free for private repos) hg would have become the defacto standard. Its just much easier to work with for most development workflows.