<div dir="ltr"><div class="gmail_extra">On Wed, Jan 9, 2013 at 10:03 PM, Sean Farley <span dir="ltr"><<a href="mailto:sean.michael.farley@gmail.com" target="_blank">sean.michael.farley@gmail.com</a>></span> wrote:<br>
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":1qv">* branching<br>
  - git has light-weight branches (this means that the branch metadata<br>
is not written in the changeset)<br>
  - mercurial calls these things bookmarks<br></div></blockquote><div><br></div><div style>Bookmarks have always been an extension that you have to explicitly enable (along with color, pager, graphlog, etc). Branches, which most people agree are bad design and don't use, are there by default. Quite importantly, bookmarks are *fragile* in that they can move around indirectly as a side-effect of an operation that does not directly reference the bookmark. Worse, when that happens, there is no way to recover the metadata. (It is ironic that the system written in a garbage-collected language does not have garbage collection while the system written in C has garbage collection.)</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":1qv">
<br>
The important thing to remember about using mercurial branches is that<br>
they are just like svn (i.e. permanent). So, if you're looking for a<br>
light-weight branches then simply use mercurial's bookmarks. You might<br>
as well forget about the `branch` command if want to compare to git.<br>
<br>
Unfortunately, Jed is right that bookmarks have some rough spots but<br>
1) it's finally being dog-fooded and 2) development with branches /<br>
bookmarks in mercurial will be much better after changeset filtering<br>
is implemented (which looks like it was pushed to crew today,<br>
actually). I haven't seen any problems using bookmarks in my everyday<br>
workflow, especially with evolution.<br></div></blockquote><div><br></div><div style>They've had more than five years of yet-another-branch-like-thing.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div id=":1qv">
<br>
* user interface<br>
  - git has notoriously had a bad interface and even when I think some<br>
command will do what I want, it somehow messes up<br></div></blockquote><div><br></div><div style>Familiarity. Both have quirks.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div id=":1qv">
  - mercurial has a pretty clean interface for the most part (and more<br>
importantly) makes typing shorter commands possible<br>
<br>
* speed<br>
  - tough to really say now that Bryan O'Sullivan's patches are in<br>
mercurial and he's actively working on that front (for Facebook … who<br>
still uses subversion)<br>
<br>
* mutable history<br>
  - git decides this based on whether there is anything "pointing"<br>
  - mercurial decides what is rewritable by the phase (public, draft, secret)<br>
<br>
This last bit of mutable history is what I've found to be an<br>
indispensable workflow. I haven't seen any comparison of this<br>
mercurial feature with modern git (to be fair, it's with a develop<br>
version of mercurial).</div></blockquote></div><div class="gmail_extra"><br></div>Phases are like having a terminal that automatically locks when idle for 1 minute. Sure, it's "safer", but it's more time fiddling with the lock.<br>
<br></div></div>