6 ms·

Cool. The changelog lists lots of updates; I'd be interested to hear from those who have had more experience with Git as to whether this improves Mercurial's st

by shutter 18y ago

Cool. The changelog lists lots of updates; I'd be interested to hear from those who have had more experience with Git as to whether this improves Mercurial's stance versus Git.

gecko 18y ago
So, disclaimer: I'm a Mercurial fan. There are two big things git has traditionally done better than Mercurial: lightweight branching, and rebasing. Both were possible in Mercurial using mq (plus qguards, in the case of lightweight branching), but the experience was rather clumsy. I didn't mind putting up with it, since, at the time the two systems came out, Mercurial was markedly easier to use than git. But, over the last year, git closed a lot of the usability gap, while Mercurial has held almost completely still, and that's resulted in a lot of arguments that Mercurial's time had passed, and git was the way to go. The good news is that this release fully eliminates git's first advantage, and either eliminates, eliminates and beats, or fails to address the second, depending on where you're coming from. The easy news to process: the rebase extension enables full git-style rebasing, end of story. You can do an automatic pull and rebase via `hg pull --rebase`, if that's what you want, or you can do more customized rebasing via `hg rebase`. So that's done, and, based on my use in production environments, works very well. Now, Mercurial 1.1 introduces real lightweight branching--no mq hackery--via an extension called `bookmarks`, which ships with Mercurial. These provide identical capabilities and benefits as git's local branches. The complicated discussion we can have revolves around bookmark semantics. bookmarks, like git branches, are basically "floating tags"--tags that mark a head in the repo's DAG, and that move with that head as you issue additional commits. The difference comes from the fact that bookmarks very directly expose what's going on, whereas git's branch command hides what's going on behind what I personally feel is a more intuitive UI. So, the argument is: is exposing what's actually going on better, because it gives you more power; equivalent, since the functionality provided is identical; or worse, because too much implementation is exposed in interface. I personally need more time to sort out preconceived bias of what micorbranching should look like, from the bookmark extension in particular.
- yummyfajitas 18y ago
  Ok, a question from a darcs guy who recently switched to hg: What are the use cases for rebase and lightweight branching? I really don't understand why I should prefer rebase to simply pull + merge. Also, is lightweight branching just a performance hack, or is there more to it?
  - gecko 18y ago
    Rebasing avoids cluttering up your history, and can help make your patches more useful. Instead of showing a fork in your history, followed by independent development, and then a merge, you instead show your branch applied to the tip of the other branch/repository, as if that had been your intention all along. This can result in more meaningful changesets as well: if a change upstream forces some changes to my new feature's code, it will be more useful for reviewing my feature if I rebase my changes so that they incorporate that slight fix. This is superb when you're keeping a fork of an open-source project, and have a collection of patches you want to keep applying cleanly to the remote software, for example. In my opinion, lightweight branching is mostly just a performance hack--and since Mercurial already did cloning with hard links on a local file system, you've been able to get the same performance benefits since before Mercurial 1.0. I do think it's worth understanding, though, that there's also a UI benefit to making building throwaway branches really easy, and I think it's silly to discount that purely because it's a user experience benefit. That's why I do think that having the bookmarks extension in Mercurial 1.1 will be a very good thing.
  - mechanical_fish 18y ago
    In git, a use case for rebase that I'm intimately familiar with is interoperability with SVN. You can maintain a branch that's a mirror of an SVN repository, but if you do any merging and then try to check the results into SVN the result is a train wreck. In the somewhat acid words of the git-svn manpage: Running git-merge or git-pull is NOT recommended on a branch you plan to dcommit from. Subversion does not represent merges in any reasonable or useful fashion; so users using Subversion cannot see any merges you've made. Furthermore, if you merge or pull from a git branch that is a mirror of an SVN branch, dcommit may commit to the wrong branch. The proper technique is to make a branch based on your SVN repo, make a bunch of changes on the branch (using svn rebase to keep your development branch in sync with changes on the SVN master branch, and -- god help us -- diff-and-patch if you have to merge in changes from some other git branch; this is your penance for working on an SVN-hosted project), then commit the whole thing back to SVN once you have it in shape. It sucks compared to true-blue git but is still nicer than SVN, because (e.g.) you get things like... ... the other use case for rebase, git-rebase --interactive, a.k.a. "take the last N commits and let me reorder, combine, and edit them however I want." I love this feature. See: http://blog.madism.org/index.php/2007/09/09/138-git-awsome-ness-git-rebase-interactive http://blog.madism.org/index.php/2007/09/09/138-git-awsome-n... For more useful ravings about git's features: http://tomayko.com/writings/the-thing-about-git http://tomayko.com/writings/the-thing-about-git

by shutter 18y ago

Cool. The changelog lists lots of updates; I'd be interested to hear from those who have had more experience with Git as to whether this improves Mercurial's stance versus Git.

gecko 18y ago

So, disclaimer: I'm a Mercurial fan. There are two big things git has traditionally done better than Mercurial: lightweight branching, and rebasing. Both were possible in Mercurial using mq (plus qguards, in the case of lightweight branching), but the experience was rather clumsy. I didn't mind putting up with it, since, at the time the two systems came out, Mercurial was markedly easier to use than git. But, over the last year, git closed a lot of the usability gap, while Mercurial has held almost completely still, and that's resulted in a lot of arguments that Mercurial's time had passed, and git was the way to go. The good news is that this release fully eliminates git's first advantage, and either eliminates, eliminates and beats, or fails to address the second, depending on where you're coming from. The easy news to process: the rebase extension enables full git-style rebasing, end of story. You can do an automatic pull and rebase via `hg pull --rebase`, if that's what you want, or you can do more customized rebasing via `hg rebase`. So that's done, and, based on my use in production environments, works very well. Now, Mercurial 1.1 introduces real lightweight branching--no mq hackery--via an extension called `bookmarks`, which ships with Mercurial. These provide identical capabilities and benefits as git's local branches. The complicated discussion we can have revolves around bookmark semantics. bookmarks, like git branches, are basically "floating tags"--tags that mark a head in the repo's DAG, and that move with that head as you issue additional commits. The difference comes from the fact that bookmarks very directly expose what's going on, whereas git's branch command hides what's going on behind what I personally feel is a more intuitive UI. So, the argument is: is exposing what's actually going on better, because it gives you more power; equivalent, since the functionality provided is identical; or worse, because too much implementation is exposed in interface. I personally need more time to sort out preconceived bias of what micorbranching should look like, from the bookmark extension in particular.

yummyfajitas 18y ago
Ok, a question from a darcs guy who recently switched to hg: What are the use cases for rebase and lightweight branching? I really don't understand why I should prefer rebase to simply pull + merge. Also, is lightweight branching just a performance hack, or is there more to it?
- gecko 18y ago
  Rebasing avoids cluttering up your history, and can help make your patches more useful. Instead of showing a fork in your history, followed by independent development, and then a merge, you instead show your branch applied to the tip of the other branch/repository, as if that had been your intention all along. This can result in more meaningful changesets as well: if a change upstream forces some changes to my new feature's code, it will be more useful for reviewing my feature if I rebase my changes so that they incorporate that slight fix. This is superb when you're keeping a fork of an open-source project, and have a collection of patches you want to keep applying cleanly to the remote software, for example. In my opinion, lightweight branching is mostly just a performance hack--and since Mercurial already did cloning with hard links on a local file system, you've been able to get the same performance benefits since before Mercurial 1.0. I do think it's worth understanding, though, that there's also a UI benefit to making building throwaway branches really easy, and I think it's silly to discount that purely because it's a user experience benefit. That's why I do think that having the bookmarks extension in Mercurial 1.1 will be a very good thing.
- mechanical_fish 18y ago
  In git, a use case for rebase that I'm intimately familiar with is interoperability with SVN. You can maintain a branch that's a mirror of an SVN repository, but if you do any merging and then try to check the results into SVN the result is a train wreck. In the somewhat acid words of the git-svn manpage: Running git-merge or git-pull is NOT recommended on a branch you plan to dcommit from. Subversion does not represent merges in any reasonable or useful fashion; so users using Subversion cannot see any merges you've made. Furthermore, if you merge or pull from a git branch that is a mirror of an SVN branch, dcommit may commit to the wrong branch. The proper technique is to make a branch based on your SVN repo, make a bunch of changes on the branch (using svn rebase to keep your development branch in sync with changes on the SVN master branch, and -- god help us -- diff-and-patch if you have to merge in changes from some other git branch; this is your penance for working on an SVN-hosted project), then commit the whole thing back to SVN once you have it in shape. It sucks compared to true-blue git but is still nicer than SVN, because (e.g.) you get things like... ... the other use case for rebase, git-rebase --interactive, a.k.a. "take the last N commits and let me reorder, combine, and edit them however I want." I love this feature. See: http://blog.madism.org/index.php/2007/09/09/138-git-awsome-ness-git-rebase-interactive http://blog.madism.org/index.php/2007/09/09/138-git-awsome-n... For more useful ravings about git's features: http://tomayko.com/writings/the-thing-about-git http://tomayko.com/writings/the-thing-about-git