4 ms·

What in particular do you hate about Mercurial? I'm curious as a contributor to hg if there's anything in particular that might be fixable (obviously there are

by durin42 15y ago

What in particular do you hate about Mercurial? I'm curious as a contributor to hg if there's anything in particular that might be fixable (obviously there are some sacred cows, but many things can be fixed just by turning on an extension).

kevingadd 15y ago
There are lots of little usability issues I hate, but it's not really fair to call those the reason, since git has similar usability issues. It really all comes down to patch queues: They're awful. They're so awful that they make me dread writing code and make me wish I was using Subversion or CVS. Any time I need to move changes that aren't ready for trunk yet from one machine to another I can expect to spend hours figuring out what went wrong with mq this time and probably lose some work. Exporting/importing patches, etc - none of it has ever worked right for me on the first try and I've never found documentation that explains a way to use mq without pain and suffering. In comparison, importing/exporting patches with git is a snap. The lack of a good equivalent to git's rebase -i is also unfortunate, but not really a showstopper. Hell, maybe mercurial has an equivalent by now.
- durin42 15y ago
  You don't have to use mq ever. I don't really use it anymore. I still have it enabled for the 'strip' subcommand (so I can discard revisions if I really need to), but I don't even use that. Instead, it's all rebase and histedit, with a sprinkling of bookmarks so I can keep track of many lightweight branches at once. Importing and exporting patches with hg is easy: http://selenic.com/hg/help/export http://selenic.com/hg/help/export http://selenic.com/hg/help/import http://selenic.com/hg/help/import (those links are the same output as 'hg help $topic') As for rebase -i, you want http://mercurial.selenic.com/wiki/HisteditExtension http://mercurial.selenic.com/wiki/HisteditExtension.
  - rdtsc 15y ago
    > want http://mercurial.selenic.com/wiki/HisteditExtension http://mercurial.selenic.com/wiki/HisteditExtension. That that is the another problem -- extensions. You go and read how to do something in mercurial. Go try it on your machine doesn't work. After a while realize you have to enable an extension. Why not just enable all the useful extensions.
    - durin42 15y ago
      For one: Because many, many features have sharp edges I don't want exposed to newbies. 'git reset --hard HEAD^' for example. Another: anything that's in hg proper has really strict backwards compatibility promises. Extensions let us screw around with a concept until the UI is _right_.
      - rdtsc 15y ago
        Makes sense. Maybe it is already implemented, but I imagine it would be possible to let the user know that they are attempting to use an extension and said extension is disable and suggest how to enable it. Something like Ubuntu's missing command package works. If I type a command that is missing but is installable by a package in apt, there will be a suggestion printed "It looks like you are trying to use this command, it can be installed via apt-get ..."
        durin42 15y ago
        Already done (for extensions that ship with hg): % hg fetch hg: unknown command 'fetch' 'fetch' is provided by the following extension: fetch pull, update and merge in one command use "hg help extensions" for information on enabling extensions but yeah, the story for out-of-tree extensions could probably be better. I'll mull that over (and also try to upstream some of my extensions again).
        rdtsc 15y ago
        That is great! Thanks. I might have to take a second look at hg.
- pnathan 15y ago
  Use branches if you want to have changes that aren't ready for stable. I have no understanding of why anyone would want to throw patches around instead of simply using branches.

by durin42 15y ago

kevingadd 15y ago

There are lots of little usability issues I hate, but it's not really fair to call those the reason, since git has similar usability issues. It really all comes down to patch queues: They're awful. They're so awful that they make me dread writing code and make me wish I was using Subversion or CVS. Any time I need to move changes that aren't ready for trunk yet from one machine to another I can expect to spend hours figuring out what went wrong with mq this time and probably lose some work. Exporting/importing patches, etc - none of it has ever worked right for me on the first try and I've never found documentation that explains a way to use mq without pain and suffering. In comparison, importing/exporting patches with git is a snap. The lack of a good equivalent to git's rebase -i is also unfortunate, but not really a showstopper. Hell, maybe mercurial has an equivalent by now.

durin42 15y ago
You don't have to use mq ever. I don't really use it anymore. I still have it enabled for the 'strip' subcommand (so I can discard revisions if I really need to), but I don't even use that. Instead, it's all rebase and histedit, with a sprinkling of bookmarks so I can keep track of many lightweight branches at once. Importing and exporting patches with hg is easy: http://selenic.com/hg/help/export http://selenic.com/hg/help/export http://selenic.com/hg/help/import http://selenic.com/hg/help/import (those links are the same output as 'hg help $topic') As for rebase -i, you want http://mercurial.selenic.com/wiki/HisteditExtension http://mercurial.selenic.com/wiki/HisteditExtension.
- rdtsc 15y ago
  > want http://mercurial.selenic.com/wiki/HisteditExtension http://mercurial.selenic.com/wiki/HisteditExtension. That that is the another problem -- extensions. You go and read how to do something in mercurial. Go try it on your machine doesn't work. After a while realize you have to enable an extension. Why not just enable all the useful extensions.
  - durin42 15y ago
    For one: Because many, many features have sharp edges I don't want exposed to newbies. 'git reset --hard HEAD^' for example. Another: anything that's in hg proper has really strict backwards compatibility promises. Extensions let us screw around with a concept until the UI is _right_.
    - rdtsc 15y ago
      Makes sense. Maybe it is already implemented, but I imagine it would be possible to let the user know that they are attempting to use an extension and said extension is disable and suggest how to enable it. Something like Ubuntu's missing command package works. If I type a command that is missing but is installable by a package in apt, there will be a suggestion printed "It looks like you are trying to use this command, it can be installed via apt-get ..."
      - durin42 15y ago
        Already done (for extensions that ship with hg): % hg fetch hg: unknown command 'fetch' 'fetch' is provided by the following extension: fetch pull, update and merge in one command use "hg help extensions" for information on enabling extensions but yeah, the story for out-of-tree extensions could probably be better. I'll mull that over (and also try to upstream some of my extensions again).
        rdtsc 15y ago
        That is great! Thanks. I might have to take a second look at hg.
pnathan 15y ago
Use branches if you want to have changes that aren't ready for stable. I have no understanding of why anyone would want to throw patches around instead of simply using branches.