Vim and Mercurial

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Vim and Mercurial

Tony Mechelynck
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...

For managing several Vim builds in parallel (let's say huge and tiny,
which is what I have, or maybe with and without GUI enabled) by means of
shadow directories, I've added a few lines to .hgignore (see attached
patch -- also for cscope). Bram, what do you think?

However, it seems that cscope does not follow symlinks, so it cannot be
used in a shadow directory.

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. Finally I
found that the hgext.fetch extension (distributed with Mercurial but
disabled by default) seems to do what I need, and I also found the way
to enable it (by means of .hg/hgrc), but I couldn't yet try it out -- I
found it after patch 7.2.422 was distributed and then Bram stopped for
today ;-). -- BTW there is some doubletalk in the hg manpages and help
about the difference between the first and second parent of the commit
that follows a merge (or the merge done by a fetch) but I haven't yet
grasped what it means. Oh, and I also haven't found how to remove the
nonsense label after the last @@ in a hunk of an hg diff, my hgrc
(attached) doesn't cut it (it was used to produce the attached diff).

Once I have the process steamrolled I'll update my HowTo page about
building Vim on Unix/Linux (or maybe add a third page or write a VimTip)
but I'm not there yet.


Best regards,
Tony.
--
Every little picofarad has a nanohenry all its own.
                -- Don Vonada

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

hgrc (148 bytes) Download Attachment
hgignore.diff (542 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Vim and Mercurial

Gary Johnson-4
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
Reply | Threaded
Open this post in threaded view
|

Re: Vim and Mercurial

Tony Mechelynck
On 13/05/10 23:42, Gary Johnson wrote:

> 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/

thanks for the pointers, I'll be remembering to come back to this email.

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

What I've done is made a "local changeset" and committed it, then found
out that for every new official patch it was the pull-merge-commit
rigmarole again. I expect that with the fetch extension it'll be a lot
smoother.

 From what I've seen of mq it's useful when constantly receiving or
sending patches in diff form, which is not what I do (I keep my "own
changes", which are few, in diff form because of ease of use and
robustness against other changes, but with Mercurial I get Bram's
changes in whatever format Mercurial uses internally, via hg pull). It
has a lot of subcommands and I don't have the use of all that ATM.


Best regards,
Tony.
--
!07/11 PDP a ni deppart m'I  !pleH

--
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
Reply | Threaded
Open this post in threaded view
|

Re: Vim and Mercurial

Navdeep Parhar
On Fri, May 14, 2010 at 05:11:15AM +0200, Tony Mechelynck wrote:
...
> From what I've seen of mq it's useful when constantly receiving or
> sending patches in diff form, which is not what I do (I keep my "own
> changes", which are few, in diff form because of ease of use and
> robustness against other changes, but with Mercurial I get Bram's
> changes in whatever format Mercurial uses internally, via hg pull).
> It has a lot of subcommands and I don't have the use of all that
> ATM.

I maintain my own patches against vim and other software using mq and
it's fairly painless (imho).  Here is how it goes:

hg clone ....
hg qinit -c
hg qnew -m "Add feature foo" foo.diff
vim .../foo.c
hg qrefresh

(when it's time to resync with vim changes)
hg qpop -a
hg pull -u
hg qpush -a

Regards,
Navdeep

--
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
Reply | Threaded
Open this post in threaded view
|

Re: Vim and Mercurial

Mike Williams
In reply to this post by Tony Mechelynck
On 14/05/2010 04:11, Tony Mechelynck wrote:
> On 13/05/10 23:42, Gary Johnson wrote:
>> On 2010-05-13, Tony Mechelynck wrote:
[snip]

>>> 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
>>
>
> What I've done is made a "local changeset" and committed it, then found
> out that for every new official patch it was the pull-merge-commit
> rigmarole again. I expect that with the fetch extension it'll be a lot
> smoother.
>
>  From what I've seen of mq it's useful when constantly receiving or
> sending patches in diff form, which is not what I do (I keep my "own
> changes", which are few, in diff form because of ease of use and
> robustness against other changes, but with Mercurial I get Bram's
> changes in whatever format Mercurial uses internally, via hg pull). It
> has a lot of subcommands and I don't have the use of all that ATM.

The mq extension for managing a stack of local patches/local changes.
The usual idiom is to pop all currently active patches (hg qpop --all)
to get back to the base repo status, do a pull and update and then push
all that patches back onto the source files (hg qpush --all or named
patch if don't want all to be reapplied).

mq is a nice little system for working on changes while keeping your
local repo in line with the main one and well worth getting familiar with.

HTH - TTFN

Mike
--
I was denied life insurance, they said I had to get a life first.

--
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
Reply | Threaded
Open this post in threaded view
|

Re: Vim and Mercurial

Markus Heidelberg
In reply to this post by Tony Mechelynck
Tony Mechelynck, 2010-05-14 05:11:
> >> 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.

You always have to merge, even if a patch from Bram doesn't touch the
same file as your local changes.

> What I've done is made a "local changeset" and committed it, then found
> out that for every new official patch it was the pull-merge-commit
> rigmarole again. I expect that with the fetch extension it'll be a lot
> smoother.

Maybe you want to enable the rebase extension and use "hg pull --rebase"
to keep your local changes on top of the history.

Markus

--
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
Reply | Threaded
Open this post in threaded view
|

Re: Vim and Mercurial

Tony Mechelynck
On 14/05/10 19:06, Markus Heidelberg wrote:

> Tony Mechelynck, 2010-05-14 05:11:
>>>> 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.
>
> You always have to merge, even if a patch from Bram doesn't touch the
> same file as your local changes.
>
>> What I've done is made a "local changeset" and committed it, then found
>> out that for every new official patch it was the pull-merge-commit
>> rigmarole again. I expect that with the fetch extension it'll be a lot
>> smoother.
>
> Maybe you want to enable the rebase extension and use "hg pull --rebase"
> to keep your local changes on top of the history.
>
> Markus
>

Update after Bram published changes up to 7.2.429:
- The fetch extension does exactly what I need, it even supplies a
sensible merge comment, viz. "Automated merge with
https://vim.googlecode.com/hg/". (From the docs: if there had been no
need to merge it would have done a pull-and-update instead, just like hg
pull -u)
- There was one file which I had forgotten to ignore: runtime/doc/tags,
which is rebuilt at every install (and mine is different from Bram's
because I have brought float-ext.txt into the local repo for consistency
with Bill McCarthy's changes to eval.c).


Best regards,
Tony.
--
Mind!  I don't mean to say that I know, of my own knowledge, what there
is particularly dead about a door-nail.  I might have been inclined,
myself, to regard a coffin-nail as the deadest piece of ironmongery in
the trade.  But the wisdom of our ancestors is in the simile; and my
unhallowed hands shall not disturb it, or the Country's done for.  You
will therefore permit me to repeat, emphatically, that Marley was as
dead as a door-nail.

--
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
Reply | Threaded
Open this post in threaded view
|

Re: Vim and Mercurial

Tony Mechelynck
On 14/05/10 21:08, Tony Mechelynck wrote:

> On 14/05/10 19:06, Markus Heidelberg wrote:
>> Tony Mechelynck, 2010-05-14 05:11:
>>>>> 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.
>>
>> You always have to merge, even if a patch from Bram doesn't touch the
>> same file as your local changes.
>>
>>> What I've done is made a "local changeset" and committed it, then found
>>> out that for every new official patch it was the pull-merge-commit
>>> rigmarole again. I expect that with the fetch extension it'll be a lot
>>> smoother.
>>
>> Maybe you want to enable the rebase extension and use "hg pull --rebase"
>> to keep your local changes on top of the history.
>>
>> Markus
>>
>
> Update after Bram published changes up to 7.2.429:
> - The fetch extension does exactly what I need, it even supplies a
> sensible merge comment, viz. "Automated merge with
> https://vim.googlecode.com/hg/". (From the docs: if there had been no
> need to merge it would have done a pull-and-update instead, just like hg
> pull -u)
> - There was one file which I had forgotten to ignore: runtime/doc/tags,
> which is rebuilt at every install (and mine is different from Bram's
> because I have brought float-ext.txt into the local repo for consistency
> with Bill McCarthy's changes to eval.c).
>
>
> Best regards,
> Tony.

All right, I think I have the process reasonably steamrolled, with local
changes to the source (otherwise there would hardly be anything to
document), and using the hg fetch extension; and I have documented it:
http://vim.wikia.com/wiki/Getting_the_Vim_source_with_Mercurial

John's bot will no doubt add the {{TipProposed}} header at the top some
time soon.


Best regards,
Tony.
--
Good day for water sports.  Take a bath with a friend.

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