On 2010-05-13, Tony Mechelynck wrote:
> I've started trying to learn Mercurial as used with Vim, but the
> learning curve is steep, not the least because AFAICT the only docs
> consist in three very long manpages, plus the "hg help" function which
> only displays a few lines at a time (let's say between 10 and 60) and
> you cannot know what an "extension" exactly does before you enable it:
> hg help <command> gives an error if <command> is disabled, which is by
> default the case of most extensions; the list of extensions under "hg
> help extensions" (there is none in the manual) consists of only one line
> per extension. -- Ah la la, I've been too cuddled by the Vim help, I've
> lost the habit of puzzling out an answer through extremely long manpages
> and extremely short help screens, where help screens and manpages each
> contain info not available in the other set...
I've recently started learning Mercurial myself, largely for
managing my own work. I've been using Google to find the answers to
most of my questions. There is a lot of good information,
especially on extensions, on the wiki:
http://mercurial.selenic.com/wiki/
Google has also revealed a number of good tutorials, e.g.,
http://mercurial.selenic.com/wiki/UnderstandingMercurial
http://mercurial.selenic.com/wiki/Tutorial
http://hginit.com/
http://hgbook.red-bean.com/
http://mercurial.aragost.com/kick-start/
> When building exclusively from "official" sources, Mercurial is (all in
> all) rather easy to use (once "hg clone https://vim.googlecode.com/hg/
> vim" to create the repository, which includes a reasonable .hgignore for
> compiling one build only from vanilla sources, and any number of times
> "hg pull -u" as updates are published). However, I have a few "home
> patches", one of which adds an "Extra patch" near the end of version.c
> -- with the patches distributed by ftp this was no problem, as this
> change is after the added patches: patch doesn't even notice it. But
> with Mercurial as distributed it meant hg pull, hg merge, hg commit (3
> separate Mercurial functions) for each patch (or set of patches) pulled,
> because Mercurial notices that version.c has been modified by Bram and
> needs to be merged -- every time -- with the change I made.
There's a whole Mercurial subsystem (my term) for managing patches,
Mq, but it seems really complicated, so I haven't tried using it.
You might take a look at the rebase and attic extensions for a
simpler approach to managing your own patches.
HTH,
Gary
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
