4 ms·
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 pro
by 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 agoMakes 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 agoAlready 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 agoThat is great! Thanks. I might have to take a second look at hg.