4 ms·

Git and Mercurial are pretty similar, but I must say that I don't like the Mercurial branching model. It forces me to have a repository for every topic branch w

Git and Mercurial are pretty similar, but I must say that I don't like the Mercurial branching model. It forces me to have a repository for every topic branch when I'm contributing to an open source project. You can read more about this here: [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... [2] http://hgbook.red-bean.com/read/managing-releases-and-branchy-development.html http://hgbook.red-bean.com/read/managing-releases-and-branch...

masklinn 16y ago
> It forces me to have a repository for every topic branch when I'm contributing to an open source project. You might want to read the first link you gave, I think.
- ciupicri 16y ago
  What do you mean? I read that guide almost an year ago and decided that branching with clones is the best option for me.
  - tednaleid 16y ago
    Yet you're complaining about that option and saying that it doesn't support the branching model as git. It does support it, but you rejected it.
    - ciupicri 16y ago
      Here's my current setup: I have 2 clones/repositories of Satchmo. [1] is for bug fixing and [2] for translations. I've asked for a better solution on the #mercurial channel and no one has offered it to me. If you have a better idea that's similar to git[3] (1 repo), I'm waiting for it. Until then I'll complain about what Mercurial is offering me, just like Groxx and cdavid (see above). [1] http://bitbucket.org/ciupicri/satchmo http://bitbucket.org/ciupicri/satchmo [2] http://bitbucket.org/ciupicri/satchmo-l10n-ro http://bitbucket.org/ciupicri/satchmo-l10n-ro [3] http://github.com/ciupicri/cobbler/tree/master-pagination-bugfix http://github.com/ciupicri/cobbler/tree/master-pagination-bu...
      - tednaleid 16y ago
        Maybe I'm missing some nuance in what you're asking for, but in mercurial, you should be able to just create a named branch to get the same effect: hg branch bug-fixes hg commit -m "creating bug fix branch" hg update default hg branch translations hg commit -m "creating translations branch" then you can just "hg update <branchname>" to do an in place switching between branches (just like git checkout). I wouldn't use 2 separate repositories for that, just one. We've got multiple named branches at work (I also use bookmarks with development branches fairly heavily, but that's a slightly different topic).
        ciupicri 16y ago
        Wouldn't these branches be permanent? They might be fine for translations, but I doubt upstream would accept one for a bug fix. As for bookmarks, if I understand this correctly, I have to convince upstream to use them. With git I can create a branch in my repository and upstream can pull my changes in whatever branch it wishes too. I don't need to convince anyone to do anything else, besides accepting my patches.
        tednaleid 16y ago
        Sorry, I misunderstood your use case for the bug-fix branch. Yes, you likely wouldn't want a named branch for that. I use local bookmarks for this. It lets you think of it as a branch locally (it's really a floating tag), but doesn't (automatically) get pushed out.
Groxx 16y ago
I can't stand Mercurial branches. They make no sense once you've tasted Git's. Heck, Mercurial users / developers / websites as much as admit it sucks. The most-recommended way to branch that I've seen is to clone the remote, never develop on that copy (a "pristine" clone), and clone that repo to make your branches, pushing back into your pristine when you're ready to upload. Git? Just branch and code.
- cdavid 16y ago
  I concur to that. I find Hg branching model messy: there are clones, named branches, bookmarks and anonymous branches. They all have different features in term of how you can share them, etc... Also, I find comparing branches (through log, diff, etc...) a bit painful, especially because of inconsistencies between naming in hg - git naming is less user friendly, but much more consistent. IOW, Git complexity comes from a f*cked-up UI, but hg simplicity is only superficial. Any semi-advanced usage in hg requires queues, a lot of plugins, etc... whereas git supports all that out of the box. Some simplicity in hg is also seriously broken - the "simple" version naming is a very bad idea in DVCS. Inevitably, different people will refer to the same revision (r1234) which is in fact a different revision because they are relative to different repositories. Merging is also not that great in hg: I really miss git index when I need to resolve conflict. But I have a strong dislike for kdiff3 and that sort of tools.
  - Groxx 16y ago
    I sort of like that revision naming, actually. As long as nobody does that, it does simplify things at times. Though no more than bookmarks do, and they can be descriptive instead of iterative.
    - cdavid 16y ago
      The issue is exactly that people like it - everyone prefers a simple number to an hash, even if your name is Linus Torvald. But in DVCS, it is impossible to keep this naming consistent, and the cases where they work and don't may become quite subtle.
- 16y ago

masklinn 16y ago

> It forces me to have a repository for every topic branch when I'm contributing to an open source project. You might want to read the first link you gave, I think.

ciupicri 16y ago
What do you mean? I read that guide almost an year ago and decided that branching with clones is the best option for me.
- tednaleid 16y ago
  Yet you're complaining about that option and saying that it doesn't support the branching model as git. It does support it, but you rejected it.
  - ciupicri 16y ago
    Here's my current setup: I have 2 clones/repositories of Satchmo. [1] is for bug fixing and [2] for translations. I've asked for a better solution on the #mercurial channel and no one has offered it to me. If you have a better idea that's similar to git[3] (1 repo), I'm waiting for it. Until then I'll complain about what Mercurial is offering me, just like Groxx and cdavid (see above). [1] http://bitbucket.org/ciupicri/satchmo http://bitbucket.org/ciupicri/satchmo [2] http://bitbucket.org/ciupicri/satchmo-l10n-ro http://bitbucket.org/ciupicri/satchmo-l10n-ro [3] http://github.com/ciupicri/cobbler/tree/master-pagination-bugfix http://github.com/ciupicri/cobbler/tree/master-pagination-bu...
    - tednaleid 16y ago
      Maybe I'm missing some nuance in what you're asking for, but in mercurial, you should be able to just create a named branch to get the same effect: hg branch bug-fixes hg commit -m "creating bug fix branch" hg update default hg branch translations hg commit -m "creating translations branch" then you can just "hg update <branchname>" to do an in place switching between branches (just like git checkout). I wouldn't use 2 separate repositories for that, just one. We've got multiple named branches at work (I also use bookmarks with development branches fairly heavily, but that's a slightly different topic).
      - ciupicri 16y ago
        Wouldn't these branches be permanent? They might be fine for translations, but I doubt upstream would accept one for a bug fix. As for bookmarks, if I understand this correctly, I have to convince upstream to use them. With git I can create a branch in my repository and upstream can pull my changes in whatever branch it wishes too. I don't need to convince anyone to do anything else, besides accepting my patches.
        tednaleid 16y ago
        Sorry, I misunderstood your use case for the bug-fix branch. Yes, you likely wouldn't want a named branch for that. I use local bookmarks for this. It lets you think of it as a branch locally (it's really a floating tag), but doesn't (automatically) get pushed out.

Groxx 16y ago

I can't stand Mercurial branches. They make no sense once you've tasted Git's. Heck, Mercurial users / developers / websites as much as admit it sucks. The most-recommended way to branch that I've seen is to clone the remote, never develop on that copy (a "pristine" clone), and clone that repo to make your branches, pushing back into your pristine when you're ready to upload. Git? Just branch and code.

cdavid 16y ago
I concur to that. I find Hg branching model messy: there are clones, named branches, bookmarks and anonymous branches. They all have different features in term of how you can share them, etc... Also, I find comparing branches (through log, diff, etc...) a bit painful, especially because of inconsistencies between naming in hg - git naming is less user friendly, but much more consistent. IOW, Git complexity comes from a f*cked-up UI, but hg simplicity is only superficial. Any semi-advanced usage in hg requires queues, a lot of plugins, etc... whereas git supports all that out of the box. Some simplicity in hg is also seriously broken - the "simple" version naming is a very bad idea in DVCS. Inevitably, different people will refer to the same revision (r1234) which is in fact a different revision because they are relative to different repositories. Merging is also not that great in hg: I really miss git index when I need to resolve conflict. But I have a strong dislike for kdiff3 and that sort of tools.
- Groxx 16y ago
  I sort of like that revision naming, actually. As long as nobody does that, it does simplify things at times. Though no more than bookmarks do, and they can be descriptive instead of iterative.
  - cdavid 16y ago
    The issue is exactly that people like it - everyone prefers a simple number to an hash, even if your name is Linus Torvald. But in DVCS, it is impossible to keep this naming consistent, and the cases where they work and don't may become quite subtle.
16y ago