Hacker News new | past | comments | ask | show | jobs | submit login

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.




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/import (those links are the same output as 'hg help $topic')

As for rebase -i, you want http://mercurial.selenic.com/wiki/HisteditExtension.


> want 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.


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_.


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 ..."


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).


That is great! Thanks. I might have to take a second look at hg.


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.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: