3 ms·

> hg bookmarks are the equivalency to git branches. In my opinion, this is not all good although it clearly solves a problem. Having two somewhat non-orthogona

by exDM69 13y ago

> hg bookmarks are the equivalency to git branches. In my opinion, this is not all good although it clearly solves a problem. Having two somewhat non-orthogonal features for branching undoes a part of the easier learning curve argument. You end up having to educate people whether to use bookmarks or branches and in what situations. If branches are permanent, who are allowed to create branches? Everyone or just maintainers/core developers? What if a would-be contributor creates a branch that isn't wanted as a permanent branch or has a bad name? Need to rename a branch or do some tricks to comply with the upstream conventions? It ends up being a similar social/political issue to git rebase vs. git merge. The easier learning curve argument was more relevant when people were coming to hg from svn/cvs backgrounds. These days more and more people are coming from a git background.

dhimes 13y ago
Indeed, without a dictator controlling the 'central repo' you do have the issue of contributors borking your branches. As far as learning curve, the branch/bookmark confusion doesn't seem to be all that big in practice IMO.
alwillis 13y ago
>Having two somewhat non-orthogonal features for branching undoes a part of the easier learning curve argument. You end up having to educate people whether to use bookmarks or branches and in what situations. Like most things, it depends. But mostly no, it doesn't impact the learning curve issue, especially if your team uses the git branching model, you never even have to address Mercurials named branches. I'd also say all the other advantages of Mercurial far out-weigh something a conceptually simple as "use bookmarks for git-like, non-permanent branches; use named branches for permanent branches." Done.
alwillis 13y ago
This article is a little dated, but it conveys the flexibility of Mercurial branching.[1] I don't know why git users get so hung up on named branches—you never have to use them if they don't make sense for your project. [1] http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/ http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-me...

by exDM69 13y ago

dhimes 13y ago

Indeed, without a dictator controlling the 'central repo' you do have the issue of contributors borking your branches. As far as learning curve, the branch/bookmark confusion doesn't seem to be all that big in practice IMO.

alwillis 13y ago

>Having two somewhat non-orthogonal features for branching undoes a part of the easier learning curve argument. You end up having to educate people whether to use bookmarks or branches and in what situations. Like most things, it depends. But mostly no, it doesn't impact the learning curve issue, especially if your team uses the git branching model, you never even have to address Mercurials named branches. I'd also say all the other advantages of Mercurial far out-weigh something a conceptually simple as "use bookmarks for git-like, non-permanent branches; use named branches for permanent branches." Done.

alwillis 13y ago

This article is a little dated, but it conveys the flexibility of Mercurial branching.[1] I don't know why git users get so hung up on named branches—you never have to use them if they don't make sense for your project. [1] http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/ http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-me...