I'm going to slowly move on from Mercurial
mercurial-scm.org
mercurial-scm.org
Transitioning away after 10+ years is a sign of several positive things:
* Creating a successful project that lasts 10+ years
* Having the perseverance, patience, and willpower to guide that project for its lifetime
* Creating a healthy community whom you are able to transition day-to-day responsibility of that project to
Matt has accomplished something that most of us never will. I'm envious of what he has accomplished and that he is able to walk away from a healthy and successful project. Truly a remarkable accomplishment.
I used hg before moving to git and always preferred the clean, single language implementation vs the scripts and general hackish nature that git offered as an alternative. As a result, it was a nice perk for a long time that hg worked much better than git on Windows.
Docs:
https://selenic.com/hg/help/revsets
A complete example, which appears to have some popularity in Mozilla:
http://jordi.inversethought.com/blog/customising-mercurial-l...
edit: Sorry, the --decorate part would be with template, the --all is kind of like a revset, and the --graph part is well, --graph.
Except for the --graph part which would be accomplished with --graph of course
> Revsets are kind of like gitrevisions(7), but much more powerful.
And easier to read and write too.
Yes, it's a way to select sets of revisions by filtering and merging existing sets.
> and are the queries thus-specified ones that have direct analogs in git and can be done in git using git's API?
I don't think so, not all of the filter operations are available, but more importantly I don't think git supports arbitrary sets of revisions, only fairly basic relatively continuous ranges (that's the idea I get from gitrevisions(7) anyway)
Up until Blekko I had pretty much been a perforce user (both at NetApp and at Google) and git was "that weird system you had to use to check in kernel changes". Blekko used Mercurial and I had no opinion as I had no experience. But over the years using hg at work and then starting up a github account to learn git, I saw the writing on the wall. Hg was the betamax of source code management systems. Clean, elegant, reliable, and not mainstream.
I wasn't there to witness this, but I repeat it because it's actually kind of hard to dig up this history. I don't know of a single place that neatly chronicles the whole transition from bitkeeper -> git/mercurial.
I remember using Mercurial very early on in its lifetime, during my first internship at IBM, because Xen used it.
Mercurial also ran on Windows far, far earlier than Git did. A few projects (notably Mozilla) selected Mercurial for that reason, because they had developers on Windows.
Unfortunately, Mercurial took longer to develop some of its infrastructure, such as a repository structure optimized for performance, fast branches without making a separate working directory for each, and history editing capabilities. Today, as far as I know, Mercurial does have all of those things (some through plugins).
> Some git users relied on cogito for another year or so, as simple things like `git-commit` still had to be manually handcrafted out of `git-commit-tree`.
Many people (myself included) also used cogito as a crutch for a while longer, until really internalizing the value of the git index, because cogito defaulted to bypassing the index. I originally saw the index as an obstacle to the commit model I'd gotten used to from subversion. Today, I find it a critical part of git's culture of making small commits with one logical change each.
Ouch, yet another way in which running on Windows can lead to poor technical decisions.
In my own case, I really preferred hg's command congruence to SVN; git's deceptive similarity took a long time to get over.
> I originally saw the index as an obstacle to the commit model I'd gotten used to from subversion. Today, I find it a critical part of git's culture of making small commits with one logical change each.
Same here, on both counts. I'd never go back, now, but it did take time to understand the benefits.
That's quite dismissive of Windows...
I didn't see any indication in the parent comment (or in general, really) that Windows support was the cause of Mercurial's difficulty in implementing those features.
I've never heard from anyone that choosing/using Mercurial was a poor decision. Are you biased?
I liked hg too, but as the passage of time has indicated choosing it for one's project would have been a mistake, as git has effectively won.
Separately, GitHub has won the "place where you share you project code" prize that used to belong to sourceforge.
Edit: to be clear, the kind of "everything" I have in mind is the code review system which now has to support two version control tools. Indeed if we'd used git from the start there might well have been an off-the-shelf code review tool we could have used without putting multiple man years of effort into customisations.
Not that this has changed much, the CLI git has been renamed to "git on windows" but fundamentally you're still installing msys (2) to run git.
That issue is greatly mitigated by the existence of libgit2 though, it builds natively on windows (and just about everything else) so windows git (GUI) clients need not depend on CLI git.
You're installing msys to run git because (I guess) it was considered the git CLI would be useless without a decent shell. Would you see yourself use Git or Mercurial in cmd?
Git itself in Git for Windows, afaik, is not actually an msys program, and uses native win32 APIs.
Are you implying that choosing hg was a poor technical decision?
Or are you just making the general observation that if you include non-technical requirements when choosing a tool (and if we accept that running on a specific set of platforms is not a technical requirement...) then you might not end up with the choice that would have been best if all the requirements were purely technical?
If the former, then you should elaborate. As far as I was able to determine when I evaluated both hg and git is that they are essentially equivalent technically. Git's default interface makes some things visible that hg keeps behind the scenes, but these are all a quick hg extension installation away for those who want them.
Today, yes. Significant work went into getting Mercurial's internals up to parity with Git's, and conversely into getting Git's UI up to parity with Mercurial's.
Don't discount the effect that familiarity with a tool or process can have on your perception of it. The most succinct explanation of this effect that I know comes from the title of a post on the Light Table blog called, "Pain We Forgot".
Coming from a Mozilla-influenced, pre-GitHub-explosion background, I'm one of those people always favored Mercurial but used both out of necessity. Mostly that meant using hg for my own stuff that is most likely never to see the light of day and git for almost everything else. But I also ended up calling it quits on Mercurial and pulled the trigger on git-for-everything last week.
So, having just written (what should be a completely unnecessary) tool to dump out stats about files' line ending conventions, again, I'll say that Git has a long way to go.
(And before you ask, yes the problem manifests itself using the latest version of Git, and there's nothing exotic or wacky to my workflow, nor am I witnessing the effect of interplay with other tools of dubious quality. This is an outright case of Git's tendency to drop the ball and then gesture in the vague direction of a poorly documented non-fix that cuts orthogonally to the problem it's supposed to be solving.)
(Another pre-emptive response: yes I'm aware of both core.autocrlf and "text eol", but those are exactly the sort of sideways-cutting non-fixes that I'm talking about.)
I expect that if a file uses CRLF everywhere, `git merge` will not leave it in a state with mixed line endings after inserting conflict resolution markers that end in LF instead of CRLF.
This shouldn't require a configuration option, but if it does, fine. However, Git doesn't even seem to have this.
What it does have are 'autocrlf' and 'eol' and 'text' options/attributes. For anyone who mentions those, I'm going to ask that you be familiar with not just what those actually control, but also how they're documented in the git man pages and in the book from git-scm.org—the entire premise was a discussion about Git's user-facing parts. By either source, those options control line normalization (i.e., implicit automatic conversion), which is not what I'm talking about. And the documentation for those is sick enough that even if they were the things to look to in order to configure this, then the idea that Git's UI is on par with Mercurial nowadays would still be wrong.
EDIT: To clarify, the desired approach for this is, "Use whatever line endings the file is already using". Git's approach to this is, "Standardize on either LF or CRLF, and at your discretion enable what amounts to some glorified git hooks to ensure that policy is followed, through the use of some obtusely documented configuration options. Make sure to work around any problems with that (e.g., when it's corrupting files that should have never been normalized) by applying another liberal layer."
Not to mention that you can't send CRLF in emails. So how are you going to email patches.
So you can shelve. When you have enabled the extension.
If I'm not mistaken, even CVS handled this better.
This is way, way better than CVS. Some people complain about how this doesn't work in place, like git or shelve, but I prefer I don't have to change anything in my main repo, like regenerate IDE files, dependency caches etc.
In any event, I've always like how this worked.
In a way, actually, that still seems to be the case. The Mercurial community seems to be working hard on making enormous monolithic repositories much more performant and realiable, whereas a lot of Git community seems to prefer to merely respond "YOU'RE USING IT WRONG" to these issues (although I suspect the developers themselves are also working on some of the issues; it's just that I see the community at large as much more visible).
So there's definitely a sense to me that Mercurial is the better VCS because it will quietly support whatever development model you want to use, whereas Git tries to force you to use the One True Model™--and I'm firmly in the camp that development tools should support developers' habits, not force them.
Wow, I can't disagree with that notion more. I've been on many projects that use git and practically every one used git in different ways. I've never felt that git was trying to force a particular workflow on me. Git's greatest strength, to me, has always been its toolbox nature—you can make it do whatever you like (want to comb through your entire repo and change someone's email address, or backdate an entire branch? No problem!).
Considering the number of tools based on the Git data model to do completely unrelated things (I'm thinking about e.g. bup or git-annex). I wouldn't say that's Git imposes you a One True Model. Also, Git doesn't restrict you to an arbitrary number of parents on a commit ;).
BTW,
> The Mercurial community seems to be working hard on making enormous monolithic repositories much more performant and realiable
The irony is that to do so, Mercurial had to bend its data model, adding (backwards incompatible) support for per-directory manifests (which sound a lot like trees in Git, except the part where manifests have history attached to them, where Git only has history attached to commits).
How is this different from mercurial ? I know that the latter doesn't have the index, but is there any practical difference from the point of view of the user ? In Mercurial you can easily commit a subset of the files, or even a part of a file if you use the record extension.
It's now part of core with `hg commit -i`, although it's still experimental.
You can commit a subset of changed files in most version control systems, but it isn't smart because you didn't test that state and it's relatively easy to garble files.
Not having the index is a very practical difference for users, because it means that you do not get any editable "staging" commits, only commits that will be on the permanent record.
I understand the appeal of that, in fact Mercurial acquired similar capabilities during it's evolution, thanks to a number of extensions (for example histedit [1])
The clean solution here is to stash/shelve the changes you don't want, then commit the ones you wanted. This works pretty much the same way in either VCS.
> Not having the index is a very practical difference for users, because it means that you do not get any editable "staging" commits, only commits that will be on the permanent record.
Use hg commit [-i], hg commit --amend [-i], and hg uncommit (with evolve) to modify the most recent commit as needed. Or, frankly, just use hg shelve [-i] to do the reverse as described above.
The Git index doesn't improve upon the situation, since you still can't test the partial commit without stashing the remaining changes first. At which point you could have just done that first.
In any event, the closest equivalent of Git's index in Mercurial is MQ, not hg commit -i and friends. The difference is that in Mercurial it's opt-in rather than opt-out.
I had this hook in Mercurial on OS X:
pre-commit = mdfind -0 -onlyin . "kMDItemContentTypeTree = 'com.apple.package'" | xargs -0 hg addremove
For those not familiar with Mercurial, "hg addremove dir ..." adds any files from the specified directory that are not already in the repository, and removes from the repository any files that were from the repository that have been deleted from the specified directory.
For those not familiar with OS X, that mdfind command is finding directories in or under the current directory that have the kMDItemContentTypeTree list in the metadata includes com.apple.package. These are directories that are logically treated as if they are single files.
Suppose I am keeping a TODO list named "TODO" with my project, and I'm using OmniOutliner to organize it. The TODO list will be in a directory named "TODO.oo3". OmniOutliner will keep an XML file in that directory that has most of my TODO list. If all my TODO list consists of is formatted text, that will be all that is in there, and everything is simple. As far as any DVCS goes, I can just treat that XML file as my entire TODO list. It will be no different than a code file, except that I edit it with OmniOutliner instead of vim or TextMate.
Now suppose I add more than just simple formatted text to my TODO. OmniOutliner allows adding files as attachments. They get copied into the TODO.oo3 tree. It also allows recording audio notes, which get stored as files in TODO.oo3. Deleting an attachment in OmniOutliner will delete the file from TODO.oo3.
So what my Mercurial pre-commit hook is doing is finding any files that have been added or removed in directories like my TODO.oo3, and adds any newly added files and removes any deleted files. Files that have just had contents changed will be taken care of by the normal operation of Mercurial.
With git, I'm not sure how to handle this. There are two main issues.
1. Where to handle this. I think the adding and removing of files from the magic directories need to occur on commands that modify the index. In particular, on "add -u". However, I don't see any hook for this. Git's pre-commit hook is, unsurprisingly, for commits, which is too late.
2. Dealing with fancy things like stashes. In general going over ever git command that affect the index and making sure that magic directories are being handled right.
It would be ugly, but I'm starting to suspect it might require putting a wrapper around the git command itself, which is kind of ugly.
Another possibility is a pre-commit hook that just checks to see if any magic directories have added or removed files, and if so aborts the commit and alerts the user that they need to "git add" or "git rm" those files or add --no-verify if they want to commit anyway. It wouldn't be as clean as it was in Mercurial, but it would at least be an improvement over relying on noticing in the "git status" I almost always do before committing that I've got some add/removes in a magic directory that need to be taken care of first.
README.txt
src/
include/
doc/
TODO.oo3
I don't want to "git add" on the project directory, or any of the subdirectories other than TODO.oo3 because I don't want to pick up those files. For everywhere except TODO.oo3, "git add -u" is what I (think I) want. It's only with TODO.oo3 that I want "git add" instead of (or in addition to) "git add -u".
I mostly use "git add -p" and it misses new files, which doesn't feel right either :\
I've never understood why the index has to be forced on everyone for every commit. Apparently it's due to a belief that everyone always just munges a bunch of changes together in their working copy in a mad coding frenzy and then later realize they need to filter and separate those changes into separate commits? That happens to me from time to time, but it's not the common case. When it does happen (since I use mercurial) I can use use tools such as commit --amend, or commit <list of filenames>, or record or crecord to filter and separate the changes in my working copy into separate commits. I believe even git has some of those same options.
> I've never understood why the index has to be forced on everyone for every commit.
You can generally bypass it if making a simple commit; I use "git commit -a" all the time. But every time you use tools like "git add" on individual files, or "git add -p" on parts of files, you rely on the index.
Understanding the index also helps greatly when you need to do a merge, cherry-pick, or other similar operation; you need a staging area to work in, separate from the work tree.
Actually, with mercurial I don't need a staging area to work in separate from the working copy to perform merge, cherry-pick, or other similar operations. The index appears to be needless complication.
> such as a repository structure optimized for performance
Actually, repository structure hasn't fundamentally changed (unless you count the RevlogNG change in 0.9). There have been changes so that data on disk compresses better (the generaldelta change) and there's more underway to support new features (such as narrow clones), but they generally aren't performance-related.
I note that this is a good thing: Mercurial's repository structure allows it to do things that aren't easy for Git, especially efficient random access to history (Git's structures are generally optimized for access close to HEAD and the root of the directory tree), at the expense of requiring more disk space.
The performance improvements you've seen most likely come from more/better caching or reimplementation of time-critical code.
> fast branches without making a separate working directory for each
That was always possible. Documentation (such as the Mercurial book) suggested a clone-based workflow for reasons of convenience and because that's what people were used to at the time, not because you had to do it this way.
Why are we all playing with new programming languages when C won? Or maybe C++ won? Or Java? Did emacs or vim win? Speaking of text, did ASCII win? Which code review tool won? How about continuous integration tools? or build tools? I mean, make won, right?
None of us just pick the most widely used tool or programming language and say, "there can only be one" and then stop trying new things. Why are we doing this with version control?
For equivalents to "code collaboration tools", instead of "programming languages", "text editors" and "build tools", try "social networks" (Facebook won, MySpace lost), "network protocols" (HTTP won, FTP and Gopher lost) or "spoken languages" (English won)
I don't think this example is convincing. There are too many languages to expect arbitrary pairings to combine well. (Not to mention the fact that googling "java ruby" returns JRuby, which apparently lets you do just what you describe.)
I do agree with your last point: Even when we look at similar languages, like Python and Ruby, we don't declare one a winner, generally.
English did not won.
It might be widely spoken in the 21st century, but so were Greek, Egyptian, Latin, French, Portuguese and Spanish once upon a time.
I might be writing this in English now, but saying it won implies no change in common language will ever happen again.
Given the history of mankind and some of the countries I had the pleasure to visit on my life so far, I doubt it.
Specially since most of the people I know, do happen to speak three foreign languages on average.
Apparently not.
For what it's worth, I'm not a native English speaker.
Too many programming languages leads to too much fragmentation, not enough programmers well-versed in the languages, etc. Most times, we pick a language today based not on how optimized the language is for the problem, but on the availability of programmers who know how to use it. Haskell might be great, but if you're a business trying to build something, you'll have a much easier time hiring experienced C++ programmers. However, different languages have different strengths and weaknesses and applicability to certain problems, so you don't want to just standardize on one either. You probably wouldn't use Haskell on a project that is a good fit for C and needs low-level access to hardware.
It's not much different with version control, except that fundamentally all such systems aim to solve the exact same problem: managing and keeping track of source-code changes in a project. They go about it differently (distributed vs. non-distributed is a big factor), and offer different features, but they all want to do the exact same thing. And here again, programmer familiarity is an important factor. Working with git is not even remotely like working with ClearCase, for example. So people tend to gravitate towards popular choices, which was SVN before, and now has become git. So if you pick Hg for your project, you're going to probably have to spend more time getting contributors up to speed on it than if you picked something more popular like git.
One big factor in these debates is: how easy is it to change from one to another? Another is: how easy is it for individuals to pick their favorite and use that regardless of what others use? For programming languages and version control, you can't easily change between them, and everyone needs to be using the same one on a particular project (unless you do something where one part is written in one language and linked to another part in a different language through bindings, but this doesn't apply to version control). For editors, this isn't the case usually: any programmer can use whatever they want for the most part, and it has no effect on what others use.
As for your other examples, build tools are the same as version control: everyone has to use the same one on a project. You can't have one person build with make/autotools and another with scons and another with CMake. This doesn't mean you can't change it later if there's a compelling reason, but there's inertia to overcome once a project is built a certain way. ASCII did win, that should be obvious. Even Unicode is largely based on ASCII with utf-8.
The sheer prevalence of git "tutorials" would suggest that most programmers don't actually know how to use it.
Relevant xkcd: https://xkcd.com/1597/
I can teach Mercurial to CEO's, artists, students, etc. and some of them will be better than me on it with a week or two. All of them "get it" and it's "low friction"--they can commit and forget about it. People who need it can handle merging and the rest can ignore it. People who need branches can use it and the rest can ignore it. etc.
git doesn't allow this. git is all or nothing. Either you inload the whole mental model, or you WILL wedge your repository somehow when you execute a command that doesn't quite do what you think it does. At that point, you will spend 4 hours combing Stack Overflow for the answer. Or you will just pull up the filesystem copy of the git repo you made before executing any command other than "git pull" or "git clone".
Git's a phenomenal system, but sometimes part of me thinks it does require a PhD to fully grok.
If your install needs autotools, your install is broken. :)
The number of projects that need autotools in this day and age is vanishingly small. A small script (bash/python/perl/ruby) that checks exactly what you need and then runs make instead of copying 15 years of cargo cult m4 is far superior to autotools.
It took me a while to learn git, and the explanations I went through involved the underlying structure of the repository. They seemed excessively complicated at the time, compared to memorizing commands for cvs and svn. However, now that I understand that underlying structure, every new git tool or function just provides additional means of transforming the repository structure I have into the repository structure I want.
You don't stop learning programming once you've memorized a rote sequence of steps to run a half-dozen algorithms on a hash table. And you don't stop learning git once you've memorized a rote sequence of steps to run a half-dozen algorithms on a git repository structure.
I don't mean that to suggest that git has no room to improve in its UI; far from it. But that particular comic seems to excuse a self-perpetuating problem of not wanting to learn something useful, and instead relying on people who did learn that useful thing while simultaneously belittling them for knowing it.
Rebase, "ridiculous"? Uh oh. It's a very valuable tool and it's a quite simple concept. I agree that the user interface could be less confusing, though.
Git is just a malleable graph made out of patches. The concept is really simple (even simpler than hg). The UI could be better but the manpages are rather good at explaining how it works.
We're not in a shop where one-off merge commits are a thing anyone really cares about, so rebases usually mean things like "Somebody used the wrong committer name" or "Somebody did a branch merge incorrectly and now the history makes no sense".
The git manpages suffer from the same problem as the sudo manpage(1). I want to know how to do "X" and why it works that way, and perhaps see examples explained.
(1): The, IMO, canonical example for awful documentation design - why does a user credential switching program open with a primer to EBNF when it's hardly necessary?
Perhaps that's might apply to some git manpages, but man git-rebase in particular is really good. It has exactly what you want, example situations, the command lines to achieve them, complete with pretty ascii art diagrams.
It could still be improved, though. There might be some "oops I screwed up, what next" situations too. I think `git rebase --abort` works most of the time these days but it wasn't always so.
Honestly I think it's an accident of history that git became so popular for software development outside of Linux kernel development.
It doesn't help that git is really a good example of evolution, as seen in the UI. It would have been better if it had been architected more thoroughly before releasing for general use.
Thanks for Mercurial!
Mercurial is actually very easy to use. However, it didn't have the exact lightweight concept of git branch until they implemented bookmark a few years ago. I don't remember the limitation of bookmarks now it has been a few years since I used Mercurial...
I too thank Matt and core developers working on Mercurial. One thing I feel Matt and developers need to address is hosting hg on PyPI infrastructure instead of redirecting to their own server. From time to time the server wouldn't deliver anything and it was frustrating to see our builds fail (of course some say you should have cached the build and not hitting Mercurial server every day).
[1]: https://www.mercurial-scm.org/wiki/Presentations?action=Atta...
git's network effects mean hg needs to be 1000% better than git to replace it (much like git replaced svn, svn replaced cvs, and cvs replaced rcs).
I still have to understand how CPython could miss the symbolic meaning of this decision.
Really I think it was bitbucket's total sidelining of hg in favour of git. hg features break regularly on bitbucket and today if you visit bitbucket's home page you're greeted with "Bitbucket is the Git solution for professional teams"
If you look at the outside contributions that both projects get, this is pretty obvious. Hg is getting big changes from Facebook, Google, Mozilla, ...
Maybe the answer to the argument that a paradigm change is needed to unsettle git is simply "monolithic repos".
Also it's not true that a lot of forward-thinking, progressive, thought leader tech companies are using Lotus Notes. That is true of mercurial.
Git has at least an order of magnitude more people use it, and there is a significant and growing ecosystem around it that mercurial does not have.
Mercurial is not going to 'die' until the developers abandon it; you can still use and install it. Hell, even cvs isn't 'dead', and the last stable release was in 2008.
Mercurial will also continue to 'not be dead' for the foreseeable future, and people will use it for years to come.
...but it is already niche, and will increasingly become so.
Only time will tell, but I'd be shocked if you don't see more big name migrations away from hg over the next year or two.
People are important.
When your project forces them to use tools that don't like or don't know, they go else where. The impetus to change gathers more slowly in companies; but when you see announcements like this, like google code, like atlassian marginalizing hg, like cpython... it's crazy to suggest that it doesn't affect the way people think about mercurial.
Git may have won the network effect benefit but 10 years ago it was not at all clear how it would shake out. Mercurial did gain enough users (and large users) to remain relevant, unlike some of the other options at the time.
rcs: revision control
cvs: concurrent check outs
svn: atomic versioning (edit: originally said renames that don't suck - thanks Danny for correcting this)
git: decentralised version control
To replace git, you need a new paradigm. I don't know what it is, and I think few people here would.
Edit: to reiterate, none of this has anything to do with whether git or hg is technically better.
um.... how about a good command-line UI that doesn't require remembering all sorts of crazy command line switches?
I find it a bit odd that no-one has come up with a decent GUI or an improved command line tool for Git yet. There's plenty of attempts to supplement Git with extra commands but that's hardly an improvement. There are several implementations of the Git plumbing parts (e.g. libgit2), so making an UI on top of it wouldn't be that much work.
DCS was around before git and did not sweep the tech industry. Just like concurrent check outs weren't the reason cvs took off.
No, it was "atomic commits and single revision number for a change"
Remember CVS had non-atomic commits (part of the commit could succeed, part could fail), and per-file version numbers.
Disclaimer: I worked a lot on SVN :)
In the cvs & svn days I used a fair amount of hacks to get those two, and pretty much always failed. For svn svk was a partial solution. For cvs there was rsync, but also something else I can't even remember. Bad memories fade.
Well yes, that's the point! It would have never been the replacement for git because it's the same paradigm.
Git didn't come up with the paradigm, and neither did hg.
git and hg were direct competitors, not different generations of revision control like the list given.
less is more, in this case. :P
Of course, now that they've "won". They're basically letting the open-source stuff rot. See the recent complaint by quite a few projects about github and lack of support.
This is the problem with anointing a "winner".
Now we'll have to wait for github's replacement just like we had to wait for SourceForge's replacement.
http://alblue.bandlem.com/2011/03/mercurial-and-git-technica...
The reason git ended up overtaking mercurial is because git is more flexible. Programmers for closed-source enterprise projects worldwide flocked to git because git can be massaged into any existing development process almost painlessly.
Mercurial, in contrast, is "opinionated".
(Before you mention github -- the timeline here is also backwards, github became the de-facto standard riding on the coattails of git's success.)
The experience of migrating to DVCS's. (Anecdotal, I know, but still...)
>...but with git you're pretty much stuck with the "standard feature branching" workflow.
Git is a loose collection of file manipulation utilities, it can be cobbled together to support even the most insane workflows.
Mercurial is internally more complex than Git, as shown by the concepts you mention (bookmarks, named branches, etc) and all the various extensions. By contrast, Git is just a malleable graph of patches and tools to manipulate it. This is very well explained in the first commit(!) of git, which explains the concepts and the internal database layout.
In Git, there might be a "default workflow" that the tools are geared towards but you can use rebase and cherry-pick and all the other tools to enable just about any workflow you can imagine. Of course, this allows you to turn it into a big mess and there are some weak spots (like tracking a lot of bugfix commits backported to several release branches) but the concept is simple and sound.
It's ironic how many people claim that Mercurial is simpler, when actually git is much simpler and more elegant. You don't need named branches, bookmarks, extensions, and all that stuff. Just a graph of commits. The core of git is beautifully simple.
I don't know what's more frustrating-- people who think DVCSes need to be really really complicated, or people who endlessly complain over what color the command-line bikeshed is painted.
Can you explain? Not sure how hg being released earlier changes how many users they have. See https://en.wikipedia.org/wiki/Network_effect
GitHub and Linux gave git the network effect.
If you like hg, but want to exploit git's network effects, I strongly suggest checking it out.
I personally prefer HG over git and use it for my own personal projects, hosted on my own redmine server. I tried bitbucket, and github; the latter have s superior interface to bitbucket. which I believe why people picked github over bitbucket
hg is so much your friend here. They will actually probably get over the switch hump and use it. git that hump is much bigger and more arduous. Git is great, I like it. When you want to drag the team with you who aren't already sold, just go straight to hg every time. You're hacker, you can use either effectively and both are excellent tools.
The truth is different and Mercurial is roughly as capable as git but it's easy to miss Mercurial's power where as Git rubs your face in it (less so these days but early on, it was a brain f* to my CVS trained brain.)
But I don't really understand all the people arguing that hg is so much easier to use, and so much cleaner. Sure, in the first few years that was true, and there's architecturally better choices (not a mess of scripts, embeddable as library). But from a day to day usage, hg seems worse to me. And that includes the documentation, something that really surprised me after I had to restart using hg a year or so back.
The whole thing how hard it is to actually get rid of branches (no, I do not want to merge that branch. Yes, I don't want any central record anymore. No, I don't want to ssh into the remote box. Uh....), really bugged me. So does the need, slowly abating, to activate a lot of random plugins to get functionality that git had for years (pagers, incremental add, staging area, ...).
But I very well, and I actually mean that, might just be mind warped by having used git so long and so continually that I just don't see the problems anymore and it just seems easier. I do remember some initial difficulties understanding it, but that was in the quite early days...