3 ms·

I've been meaning to do a blog post about this for a while, but I've tried both, and so far, I prefer Git because of the way it treats branches. Git seems far f

by ufmace 13y ago

I've been meaning to do a blog post about this for a while, but I've tried both, and so far, I prefer Git because of the way it treats branches. Git seems far friendlier to the workflow of just doing stuff, and deciding how you want to commit it later. In Git, it's easy to work for a while, then decide you have 3 commits worth of changes, and one of them really ought to be in its own branch, and commit it all like that. The code that you branched off stays out of your mainline for now, but is easy to switch back to and work on some more. At any time, you can easily delete the branch, and it all effectively disappears, push it somewhere else for somebody else to work on, or merge it back into main when it's ready. Well, merging might be tricky if you wait too long, but you get the idea. Where Mercurial falls short to me is that if you create a branch in your main repository like that, then it never goes away as far as I can tell. What Mercurial really wants you to do is clone your repo, and do that work that would be a Git branch in the clone. But to do that, you have to start with a clean repo, actively decide you want to create a new branch/clone, clone your repo, and only then start doing that work in the clone. If you've already done some work, and then decided that a piece of it ought to be branched off, then your workflow is pretty messy - you have to clone with the work uncommitted, then manually move the changes over to the clone and commit them there. And switch any working directories you might have open to the clone directory to work in it. Yeah, no thanks, I'll stick with Git.

hyperbling 13y ago
or just use bookmarks and enjoy the exact same workflow as git.
zb 13y ago
That's only true for named branches. You can create an unnamed branch in hg simply by going to a point in the history (what Git would call detached head) and committing. That said, the handling of named branches remains a pain point, and at this point I would recommend people just go with Git despite the steeper learning curve.
masklinn 13y ago
> Where Mercurial falls short to me is that if you create a branch in your main repository like that, then it never goes away as far as I can tell. `bookmarks` will do that. Or you can use unnamed heads and track them manually[0] (that's essentially what bookmarks — and git branches — do). "Detached heads" are not a thing in mercurial, heads don't have to be named. [0] obviously there's nothing to track if you're just going on a short tangent, just commit your stuff, and go back to the original to merge if it was a good idea or forget if it was not. And yes you can create a bookmark "after the fact" e.g. do half a dozen commits, realise that it's going to take longer than you thought and create a bookmark for the current experiment on the tip.
- dhimes 13y ago
  This is it exactly. A lot of people miss this with hg. hg bookmarks are the equivalency to git branches. hg branches are "permanent." So you have, say, 'dev,' 'test' and 'stable' branches. Then you do hot-fixes and feature development on bookmarks, and merge them back into the branches. It's a beautiful thing, really <tears up a bit..../>
  - 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.

by ufmace 13y ago

hyperbling 13y ago

or just use bookmarks and enjoy the exact same workflow as git.

zb 13y ago

That's only true for named branches. You can create an unnamed branch in hg simply by going to a point in the history (what Git would call detached head) and committing. That said, the handling of named branches remains a pain point, and at this point I would recommend people just go with Git despite the steeper learning curve.

masklinn 13y ago

> Where Mercurial falls short to me is that if you create a branch in your main repository like that, then it never goes away as far as I can tell. `bookmarks` will do that. Or you can use unnamed heads and track them manually[0] (that's essentially what bookmarks — and git branches — do). "Detached heads" are not a thing in mercurial, heads don't have to be named. [0] obviously there's nothing to track if you're just going on a short tangent, just commit your stuff, and go back to the original to merge if it was a good idea or forget if it was not. And yes you can create a bookmark "after the fact" e.g. do half a dozen commits, realise that it's going to take longer than you thought and create a bookmark for the current experiment on the tip.

dhimes 13y ago
This is it exactly. A lot of people miss this with hg. hg bookmarks are the equivalency to git branches. hg branches are "permanent." So you have, say, 'dev,' 'test' and 'stable' branches. Then you do hot-fixes and feature development on bookmarks, and merge them back into the branches. It's a beautiful thing, really <tears up a bit..../>
- 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.