3 ms·

I use Git and Mercurial daily. They're both ok. However.. I prefer Git to mercurial, mainly because: - Git is noticeably faster for all operations (yeah, speci

by zobzu 13y ago

I use Git and Mercurial daily. They're both ok. However.. I prefer Git to mercurial, mainly because: - Git is noticeably faster for all operations (yeah, specially if you don't use GitHub for pull/push as they're slow as hell ;-) - Git has sensible default settings, for example, git log is easier than hg log|less. Similarly, git show HEAD^ is easier than hg log --patch --rev tip. (Both are easier to remember, type, and keep the logic across the tool). - Finally, Git handles everything in a generic fashion. Want to make a test branch and play around? git branch blahtest and play. With hg, you have to use queues, and weird commands such as qpop, qremove, qseries, qnew <= this is very confusing to newcomers. Basically, I feel like Git knows how to KISS better than Mercurial.

twic 13y ago
FWIW, my equivalent of 'git show' is 'hg diff -c'. It shows the patch but not the metadata; this is usually what i want. I know what you mean about hg not invoking a pager by default. I understand why the hg maintainers haven't done it, but it's still mildly annoying every time i have to throw in a |less. I have no idea what you're talking about with queues. The last time i used queues was to do stashing back before hg got a proper shelve in the core. I don't think there's any sane use case which requires them now.
masklinn 13y ago
> Git has sensible default settings, for example, git log is easier than hg log|less. cat >> ~/.hgrc [pager] pager = less -FRX [extensions] pager= There, I fixed it. > Similarly, git show HEAD^ is easier than hg log --patch --rev tip Wait, what? Those commands do completely different things. What are you trying to do? Furthermore, the assertion that `git show` is "easier" than `hg log` seems odd on its face, why is it easier to have two different commands to see the same thing, with the only difference being the length of the revision set? (yes I know `git show` can also show other objects, but that's now how you used it here). > Want to make a test branch and play around? git branch blahtest and play. With hg, you have to use queues Uh… no. You can create a bookmark, or just commit stuff (hg has no prohibition against what git calls "detached heads", they're just anonymous branches). You have to use MQ if you want to do quilt-type things. Used to be you also had to use it if you wanted to perform extensive history-rewriting, but that hasn't been the case for a few years now.
- michael_storm 13y ago
  > There, I fixed it. GP's point was about defaults, not what you can configure. Even being somewhat familiar with hg, I didn't know about the "pager" extension. > `git show` does not show a patch by default[...] It does for me, with git 1.7.9.5. > (hg has no prohibition against what git calls "detached heads", they're just anonymous branches) I have never understood why this is useful. Why not just name your heads something, anything? I wouldn't otherwise care, but I always seemed to end up with mysterious heads from who-knows-where left behind by long-ago merges.
  - masklinn 13y ago
    > GP's point was about defaults Granted, but he then describes the difficulty of typing `hg log | less`. And defaults cut both ways, I still can't fathom why `git log HEAD` would display the whole repository history. > It does for me, with git 1.7.9.5. Doesn't for me with git 1.8.5.4. Regardless I removed that part since it's not the gist of the issue and the official documentation asserts it should. > I have never understood why this is useful. Why not just name your heads something, anything? Why is a meaningless name better than no name at all? Why is git's default behaviour of losing unnamed heads altogether better than just leaving them alone?
    - michael_storm 13y ago
      > And defaults cut both ways, I still can't fathom why `git log HEAD` would display the whole repository history. I don't know why that's part of the defaults discussion, but okay. > Why is a meaningless name better than no name at all? Why is git's default behaviour of losing unnamed heads altogether better than just leaving them alone? Why would you give a meaningless name? That's a red herring. Do hg users just memorize which head is which? Mercurial users seem to get hung up on detached heads a lot. They seem to be part of the Mercurial workflow in a way that I've never really understood. But git's detached heads are at least created when I expect them to be, are easily deleted, and are easily saved. Mercurial's detached heads (or whatever they're called) want me to either merge them (why would I merge commits that popped up out of nowhere?), or close them as described in http://stackoverflow.com/questions/3688263/mercurial-beheading-a-head http://stackoverflow.com/questions/3688263/mercurial-beheadi... (apparently causing these mysterious heads to be saved forever). I much prefer a DAG with labels, instead of all this state specific to Mercurial that I have to manage.

by zobzu 13y ago

twic 13y ago

FWIW, my equivalent of 'git show' is 'hg diff -c'. It shows the patch but not the metadata; this is usually what i want. I know what you mean about hg not invoking a pager by default. I understand why the hg maintainers haven't done it, but it's still mildly annoying every time i have to throw in a |less. I have no idea what you're talking about with queues. The last time i used queues was to do stashing back before hg got a proper shelve in the core. I don't think there's any sane use case which requires them now.

masklinn 13y ago

> Git has sensible default settings, for example, git log is easier than hg log|less. cat >> ~/.hgrc [pager] pager = less -FRX [extensions] pager= There, I fixed it. > Similarly, git show HEAD^ is easier than hg log --patch --rev tip Wait, what? Those commands do completely different things. What are you trying to do? Furthermore, the assertion that `git show` is "easier" than `hg log` seems odd on its face, why is it easier to have two different commands to see the same thing, with the only difference being the length of the revision set? (yes I know `git show` can also show other objects, but that's now how you used it here). > Want to make a test branch and play around? git branch blahtest and play. With hg, you have to use queues Uh… no. You can create a bookmark, or just commit stuff (hg has no prohibition against what git calls "detached heads", they're just anonymous branches). You have to use MQ if you want to do quilt-type things. Used to be you also had to use it if you wanted to perform extensive history-rewriting, but that hasn't been the case for a few years now.

michael_storm 13y ago
> There, I fixed it. GP's point was about defaults, not what you can configure. Even being somewhat familiar with hg, I didn't know about the "pager" extension. > `git show` does not show a patch by default[...] It does for me, with git 1.7.9.5. > (hg has no prohibition against what git calls "detached heads", they're just anonymous branches) I have never understood why this is useful. Why not just name your heads something, anything? I wouldn't otherwise care, but I always seemed to end up with mysterious heads from who-knows-where left behind by long-ago merges.
- masklinn 13y ago
  > GP's point was about defaults Granted, but he then describes the difficulty of typing `hg log | less`. And defaults cut both ways, I still can't fathom why `git log HEAD` would display the whole repository history. > It does for me, with git 1.7.9.5. Doesn't for me with git 1.8.5.4. Regardless I removed that part since it's not the gist of the issue and the official documentation asserts it should. > I have never understood why this is useful. Why not just name your heads something, anything? Why is a meaningless name better than no name at all? Why is git's default behaviour of losing unnamed heads altogether better than just leaving them alone?
  - michael_storm 13y ago
    > And defaults cut both ways, I still can't fathom why `git log HEAD` would display the whole repository history. I don't know why that's part of the defaults discussion, but okay. > Why is a meaningless name better than no name at all? Why is git's default behaviour of losing unnamed heads altogether better than just leaving them alone? Why would you give a meaningless name? That's a red herring. Do hg users just memorize which head is which? Mercurial users seem to get hung up on detached heads a lot. They seem to be part of the Mercurial workflow in a way that I've never really understood. But git's detached heads are at least created when I expect them to be, are easily deleted, and are easily saved. Mercurial's detached heads (or whatever they're called) want me to either merge them (why would I merge commits that popped up out of nowhere?), or close them as described in http://stackoverflow.com/questions/3688263/mercurial-beheading-a-head http://stackoverflow.com/questions/3688263/mercurial-beheadi... (apparently causing these mysterious heads to be saved forever). I much prefer a DAG with labels, instead of all this state specific to Mercurial that I have to manage.