3 ms·

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 an

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.
  - sreque 15y ago
    I only suggested the diff/patch workflow for the simple case where you realized after making edits that you were in the wrong branch. It might even be possible to just update to the correct branch and have mercurial automatically try to remerge your changes, though I haven't tried to know for certain. I think you're taking my suggestion way out of context, though I could be misunderstanding you. Mercurial has remote-trackable bookmarks now (something I felt they needed for a long time). I agree Mercurial's branch tracking in general isn't nearly as good as git's, local branches being the biggest example. There is a local branch extension for mercurial (http://mercurial.selenic.com/wiki/LocalbranchExtension http://mercurial.selenic.com/wiki/LocalbranchExtension), but having used it a long time ago I'm not sure I'm the biggest fan. However, I firmly believe that mercurial is in the same league as git and both are more than good enough to get the job done, and each have their relative strengths and weaknesses. I also believe that the outspoken part of the git community tends to be overzealous and blind to git's faults and Mercurial's strengths.
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.

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.
- sreque 15y ago
  I only suggested the diff/patch workflow for the simple case where you realized after making edits that you were in the wrong branch. It might even be possible to just update to the correct branch and have mercurial automatically try to remerge your changes, though I haven't tried to know for certain. I think you're taking my suggestion way out of context, though I could be misunderstanding you. Mercurial has remote-trackable bookmarks now (something I felt they needed for a long time). I agree Mercurial's branch tracking in general isn't nearly as good as git's, local branches being the biggest example. There is a local branch extension for mercurial (http://mercurial.selenic.com/wiki/LocalbranchExtension http://mercurial.selenic.com/wiki/LocalbranchExtension), but having used it a long time ago I'm not sure I'm the biggest fan. However, I firmly believe that mercurial is in the same league as git and both are more than good enough to get the job done, and each have their relative strengths and weaknesses. I also believe that the outspoken part of the git community tends to be overzealous and blind to git's faults and Mercurial's strengths.

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.