On Fri, Sep 6, 2013 at 2:29 PM, Tim Chase <git@xxxxxxxxxxxxxxxxx> wrote: > On 2013-09-06 17:51, Konstantin Khomoutov wrote: >> I found this guide [1] very useful back in the time I tried to grok >> Mercurial. >> >> 1. >> http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/ I've written various blog posts about the subject: http://felipec.wordpress.com/2011/01/16/mercurial-vs-git-its-all-in-the-branches/ http://felipec.wordpress.com/2012/05/26/no-mercurial-branches-are-still-not-better-than-git-ones-response-to-jhws-more-on-mercurial-vs-git-with-graphs/ http://felipec.wordpress.com/2013/08/27/analysis-of-hg-and-git-branches/ > Indeed, after reading it, that's the most sense I've been able to make > of Mercurial's strange branching. I guess it boils down to the > following rough heuristic: > > - if you want to dink around locally, but don't want to publish your > branches (yet), default to bookmarks using "hg bookmark" Kind of, but then they added support to push bookmarks, so now you can fetch and push them, so not exactly local. In addition, they are starting to think on adding remote namespaces, like in Git, except that jon/devel becomes jon@devel. > - once you want a branch to be public, consider making a "real" > branch using "hg branch" Not necessarily. You can merge or rebase, so "the public" doesn't see the bookmark. > - if you want complete isolation in case you screw up something like > merging, use a clone I guess so. There's also the option of using the 'mq' extension, which I guess it's similar to quilt. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html