4 ms·

To be fair, the MQ and rebase extensions are shipped with mercurial, just not enabled by default. They share the same bug tracker as the main project and in my

by kisielk 15y ago

To be fair, the MQ and rebase extensions are shipped with mercurial, just not enabled by default. They share the same bug tracker as the main project and in my experience are just as well documented and tested as other bits of Mercurial. It's also been my experience that non-expert users don't understand the repository DAG model well enough to perform history rewriting reliably and without error, which I think is one reason these features are disabled by default. Finally, as of Mercurial 2.1 they now have the concept of "phases" of commits which make local non-shared commits mutable whereas commits which have already been shared are immutable. This new feature is a first step to safer history editing operations becoming more mainstream mercurial commands.

guard-of-terra 15y ago
Why should I have to assemble my DVCS from parts before I would be able to use it? If I wanted Lego I would have got one. Shelf isn't shipped with mercurial and it's really really painful without it: you make some changes to some wrong branch and now you need either shelf or major pain with rebase. If non-expert users don't understand enough to do rebase, they're screwed: they better go cry in a corner since you can't solve any non-trivial scenarios without rebase and you're going to run into those all the time. Not that I like git, but still. And since Eclipse plugin for SVN merges much better than both git and hg, I often wonder why do we bother at all :(
- sreque 15y ago
  Your comments highly suggest that you are not by any means a knowledgable mercurial user. You don't have to "assemble" mercurial from parts to do history rewriting. Enabling the relevant extensions amounts to adding a single line to a config file. I usually copy the same config file around when installing mercurial anew so that I can cut out even that step. Shelf isn't that necessary because of mq, which is bundled by default. It is very feasible to use mq as a simple shelf substitute, much easier than using it for its more complex usage scenarios. Also, for your use case, it's pretty easy to hg diff your change to a file, switch branches, and then use the GNU patch command to apply your changes on top again, so you don't even need shelf or mq to do that if you haven't checked anything in.
  - guard-of-terra 15y ago
    Well, if I need to turn on a few extensions and download obscure python scripts just to get the minimum viable experience, I consider the "Lego" badge mine. "it's pretty easy to hg diff your change to a file, switch branches, and then use the GNU patch command to apply your changes on top again" It feels like mercurial developers wanted to inflict pain on me, and makes me want to hurt them in return. See, it's three steps. It's four actually, because you also want to delete the diff file. You know how many steps did it take in SVN? Zero. When you switched branch, it just preserved all your changes and applied those back. You didn't have to do anything. Maybe it didn't work when there was a conflict - once per 100 switches. But mercurial won't let you do that - that's 100 per 100 switches.
    - wonderercat 15y ago
      Once again you're demonstrating that you really don't know how to use Mercurial, but feel the need to bash its usability anyway. hg update <branchname> will do exactly what you want. It's even the same command as in SVN.
      - guard-of-terra 15y ago
        I change a file. do hg update default get: abort: crosses branches (merge branches or use --clean to discard changes) So?
  - ramses0 15y ago
    I can't count the number of times I did: cd $PROJECT svn diff > ~/working-on-foo.patch svn revert * patch < ~/working-on-bar.patch 30 GOTO 10. Ugh. Thinking about going back to that workflow makes me physically ill. Git (as Linus says) is a STUPID content tracker. 99.9% of the time when I'm working on source code, git allowing me to do stable, local "bookmarks", keep multiple local branches (and local history) active simultaneously, and keep all my content tracked... Git has its flaws and warts but don't seriously suggest that "svn diff > ~/working-on-foo.patch" is a valid workflow. That's bringing a knife to a gunfight. I suggest that if you can understand a linked list, you can understand git. And if you're a programmer that can't understand a linked list... well... print out your "cheat sheet", here's a copy of Tortoise, and commit your code to a branch before it gets approved for main-line.
- untog 15y ago
  Why should I have to assemble my DVCS from parts before I would be able to use it? If I wanted Lego I would have got one. Because sometimes simplicity is a good thing? I'm not a Mercurial user, but there are plenty of times when decoupling features is a good thing- look at Mozilla Communicator Suite (or whatever it was called) vs. Firefox. For the record, I use git every day and I'm yet to need rebase. No, my projects aren't all that complex, nor do they have a huge number of branches. But I suspect that is the case for a lot of other people, too.
  - guard-of-terra 15y ago
    I always make changes or even commit things to the wrong branch and then struggle to move those where they're supposed to be. If you don't use branches much (like most github users) you probably don't have this problem. We have version branches, so I do.
    - josegonzalez 15y ago
      I'd like to see a reference for your comment "most github users don't use branches much".
      - eropple 15y ago
        Not sure he's accurate when referring to Github users, but I think he's probably not far off for git users in general. I mean, most git users aren't the people hanging around here. I don't see a reason to expect that more than "the simplest thing that could possibly work" to be commonplace. When I use git (I tend to use hg more because it's more friendly for Windows projects, where I often find myself), I generally work on master for personal projects where I'm the only committer. It's easier for that use case. Branches are primarily valuable, IMO, when you have multiple people bashing on it at once.
acdha 15y ago
I'm aware that they're shipped but disabled by default. I think there's something of mental blind-spot, however, because they're discouraged or treated as something only experts should use: I've never seen anything like the level of obscure error messages or cumbersome UI in any part of Mercurial which is enabled by default. I think it deserves more respect as a valid working style. I would disagree with the statement regarding history rewriting and non-expert users, to note two exceptions: Git's amend commits are extremely easy to explain and rebase is not that much harder for common cases. These same users are going to have issues with merges and rely on good tool support nearly as much in that situation, too. What I think would be welcome in Git is the very nice phased commit feature you mentioned. That's a great example of where the concern should have been directed towards the UI rather than the operation.

by kisielk 15y ago

guard-of-terra 15y ago

Why should I have to assemble my DVCS from parts before I would be able to use it? If I wanted Lego I would have got one. Shelf isn't shipped with mercurial and it's really really painful without it: you make some changes to some wrong branch and now you need either shelf or major pain with rebase. If non-expert users don't understand enough to do rebase, they're screwed: they better go cry in a corner since you can't solve any non-trivial scenarios without rebase and you're going to run into those all the time. Not that I like git, but still. And since Eclipse plugin for SVN merges much better than both git and hg, I often wonder why do we bother at all :(

sreque 15y ago
Your comments highly suggest that you are not by any means a knowledgable mercurial user. You don't have to "assemble" mercurial from parts to do history rewriting. Enabling the relevant extensions amounts to adding a single line to a config file. I usually copy the same config file around when installing mercurial anew so that I can cut out even that step. Shelf isn't that necessary because of mq, which is bundled by default. It is very feasible to use mq as a simple shelf substitute, much easier than using it for its more complex usage scenarios. Also, for your use case, it's pretty easy to hg diff your change to a file, switch branches, and then use the GNU patch command to apply your changes on top again, so you don't even need shelf or mq to do that if you haven't checked anything in.
- guard-of-terra 15y ago
  Well, if I need to turn on a few extensions and download obscure python scripts just to get the minimum viable experience, I consider the "Lego" badge mine. "it's pretty easy to hg diff your change to a file, switch branches, and then use the GNU patch command to apply your changes on top again" It feels like mercurial developers wanted to inflict pain on me, and makes me want to hurt them in return. See, it's three steps. It's four actually, because you also want to delete the diff file. You know how many steps did it take in SVN? Zero. When you switched branch, it just preserved all your changes and applied those back. You didn't have to do anything. Maybe it didn't work when there was a conflict - once per 100 switches. But mercurial won't let you do that - that's 100 per 100 switches.
  - wonderercat 15y ago
    Once again you're demonstrating that you really don't know how to use Mercurial, but feel the need to bash its usability anyway. hg update <branchname> will do exactly what you want. It's even the same command as in SVN.
    - guard-of-terra 15y ago
      I change a file. do hg update default get: abort: crosses branches (merge branches or use --clean to discard changes) So?
- ramses0 15y ago
  I can't count the number of times I did: cd $PROJECT svn diff > ~/working-on-foo.patch svn revert * patch < ~/working-on-bar.patch 30 GOTO 10. Ugh. Thinking about going back to that workflow makes me physically ill. Git (as Linus says) is a STUPID content tracker. 99.9% of the time when I'm working on source code, git allowing me to do stable, local "bookmarks", keep multiple local branches (and local history) active simultaneously, and keep all my content tracked... Git has its flaws and warts but don't seriously suggest that "svn diff > ~/working-on-foo.patch" is a valid workflow. That's bringing a knife to a gunfight. I suggest that if you can understand a linked list, you can understand git. And if you're a programmer that can't understand a linked list... well... print out your "cheat sheet", here's a copy of Tortoise, and commit your code to a branch before it gets approved for main-line.
untog 15y ago
Why should I have to assemble my DVCS from parts before I would be able to use it? If I wanted Lego I would have got one. Because sometimes simplicity is a good thing? I'm not a Mercurial user, but there are plenty of times when decoupling features is a good thing- look at Mozilla Communicator Suite (or whatever it was called) vs. Firefox. For the record, I use git every day and I'm yet to need rebase. No, my projects aren't all that complex, nor do they have a huge number of branches. But I suspect that is the case for a lot of other people, too.
- guard-of-terra 15y ago
  I always make changes or even commit things to the wrong branch and then struggle to move those where they're supposed to be. If you don't use branches much (like most github users) you probably don't have this problem. We have version branches, so I do.
  - josegonzalez 15y ago
    I'd like to see a reference for your comment "most github users don't use branches much".
    - eropple 15y ago
      Not sure he's accurate when referring to Github users, but I think he's probably not far off for git users in general. I mean, most git users aren't the people hanging around here. I don't see a reason to expect that more than "the simplest thing that could possibly work" to be commonplace. When I use git (I tend to use hg more because it's more friendly for Windows projects, where I often find myself), I generally work on master for personal projects where I'm the only committer. It's easier for that use case. Branches are primarily valuable, IMO, when you have multiple people bashing on it at once.

acdha 15y ago

I'm aware that they're shipped but disabled by default. I think there's something of mental blind-spot, however, because they're discouraged or treated as something only experts should use: I've never seen anything like the level of obscure error messages or cumbersome UI in any part of Mercurial which is enabled by default. I think it deserves more respect as a valid working style. I would disagree with the statement regarding history rewriting and non-expert users, to note two exceptions: Git's amend commits are extremely easy to explain and rebase is not that much harder for common cases. These same users are going to have issues with merges and rely on good tool support nearly as much in that situation, too. What I think would be welcome in Git is the very nice phased commit feature you mentioned. That's a great example of where the concern should have been directed towards the UI rather than the operation.