3 ms·

I use both Mercurial and Git. Mercurial is just as powerful but does a much better job at hiding the underlying model and doesn't make it as easy to shoot yours

I use both Mercurial and Git. Mercurial is just as powerful but does a much better job at hiding the underlying model and doesn't make it as easy to shoot yourself in the foot. You can see a comparison of the concepts here: http://mercurial.selenic.com/wiki/GitConcepts http://mercurial.selenic.com/wiki/GitConcepts (maybe a little biased but I think it does a good job)

rjbwork 13y ago
What I like about mercurial, and especially the TortiseHG interface to it, is that there are a TON of plugins/addons that give you a LOT of power when you need it. I've needed to strip changesets once in the 2 years of using it, and rebase once. I don't get why these are considered core functionality for git, but maybe I just don't get the workflow.
- aidenn0 13y ago
  One workflow with git where you rebase regularly is this (and it's roughly what the linux kernel uses): 3 branches: stable, staging, experimental The current release is the head of stable. Everything approved for the next release is in staging All the patches that might get pulled into staging before it becomes stable are in experimental. This is good because you find out early if two patches conflict with each other (in the "they break each other" sense, not in the VCS meaning of conflict), but unstable stuff doesn't pollute your staging branch. When a release happens, you destroy the experimental branch and recreate it from the new staging branch. Anybody who wants their patches that didn't make the cut for the release has to rebase them onto the new experimental branch.
  - rjbwork 13y ago
    I guess I don't see the benefits of this over multiple feature specific named branches off the last node on staging that got merged. Then you simply merge those each into experimental, and if all is kosher, into staging. Personal preference I guess.
    - aidenn0 13y ago
      Hmm in git you also rebase so a pull-request will merge cleanly when it would otherwise have conflicts. How does hg manage that?

rjbwork 13y ago

What I like about mercurial, and especially the TortiseHG interface to it, is that there are a TON of plugins/addons that give you a LOT of power when you need it. I've needed to strip changesets once in the 2 years of using it, and rebase once. I don't get why these are considered core functionality for git, but maybe I just don't get the workflow.

aidenn0 13y ago
One workflow with git where you rebase regularly is this (and it's roughly what the linux kernel uses): 3 branches: stable, staging, experimental The current release is the head of stable. Everything approved for the next release is in staging All the patches that might get pulled into staging before it becomes stable are in experimental. This is good because you find out early if two patches conflict with each other (in the "they break each other" sense, not in the VCS meaning of conflict), but unstable stuff doesn't pollute your staging branch. When a release happens, you destroy the experimental branch and recreate it from the new staging branch. Anybody who wants their patches that didn't make the cut for the release has to rebase them onto the new experimental branch.
- rjbwork 13y ago
  I guess I don't see the benefits of this over multiple feature specific named branches off the last node on staging that got merged. Then you simply merge those each into experimental, and if all is kosher, into staging. Personal preference I guess.
  - aidenn0 13y ago
    Hmm in git you also rebase so a pull-request will merge cleanly when it would otherwise have conflicts. How does hg manage that?