On 19/05/10 18:53, Xavier de Gaye wrote:
On Wed, May 19, 2010 at 3:36 PM, Tony Mechelynck wrote:
But even if I patched version.c to add one more line to the output of
":version", for me the latest changeset would always be my latest commit
(usually a merge, unless I recently made some new local changes), and that
would not be relevant to you all. I can do with typing "hg tip" (or, after
local changes, "hg log -l<number> -f" with a well-chosen<number>) to get
(by copy-paste from xterm etc.) the latest changeset made by Bram, which
would be the one just before my latest merge.
Hi Tony,
The following command lists the local changesets not
found in Bram's repository:
$ hg outgoing
yeah, meaning all my merges (quite a lot of them) and my few local
changes. In most cases I'm not interested in them. When discussing in
which build I had a bug, it's *Bram's* latest commit that I need, to say
(in a repeatable way) where that bug exists.
I am managing some vim patches for pyclewn with the mq extension
(Mercurial queues). The following simple command outputs the latest
changeset made by Bram on which my patches are applied:
$ hg parents -r qbase
changeset: 2172:e12b9d992389
tag: qparent
parent: 2170:cf8f86128f4c
user: Bram Moolenaar<[email protected]>
date: Sun May 16 13:56:06 2010 +0200
summary: updated for version 7.2.436
Another advantage of using mq when applying patches, is that the patch
changeset id is temporary: when you apply the patch to a more recent
Bram's repository version, a new changeset id is created and the old
one is forgotten.
Xavier
I apply the patch only once, and rather than what apparently amounts to
rollback-pull-update-reapply-commit I use "hg fetch --switch-parent"
which, in essence, applies Bram's latest changes on top of what I was
already using. One advantage is that, if not touched by Bram's changes,
any files I once modified aren't mentioned anew in the history, so I can
be sure that they don't get patched again and don't look "new" to make.
This fetch extension is simple, I think I understand it, and it suits me
perfectly. I have taken a look at that mq extension and it gave me a
headache. It may be the right tool for you, for me it isn't.
So the following lets me know (in the "normal" case) what was Bram's
latest commit:
$ hg tip
changeset: 2211:5e352d198beb
branch: vim73
tag: tip
parent: 2209:94d29057b6a7
parent: 2210:014a996ac896
user: Tony Mechelynck <[email protected]>
date: Wed May 19 23:11:58 2010 +0200
description:
Automated merge with https://vim.googlecode.com/hg/
The answer is 014a996ac896 (the most recent predecessor to this merge).
Or if I want to see what happened then, I can use almost the same
command as you did above:
$ hg parents -r tip
changeset: 2209:94d29057b6a7
branch: vim73
parent: 2202:4d1344a67d4a
parent: 2208:e741fe7a0547
user: Tony Mechelynck <[email protected]>
date: Wed May 19 02:05:18 2010 +0200
description:
Automated merge with https://vim.googlecode.com/hg/
changeset: 2210:014a996ac896
branch: vim73
parent: 2208:e741fe7a0547
user: Bram Moolenaar <[email protected]>
date: Wed May 19 21:57:45 2010 +0200
files: runtime/doc/editing.txt runtime/doc/todo.txt
src/auto/configure src/blowfish.c src/config.h.in src/configure.in
src/netbeans.c src/sha256.c src/vim.h
description:
Use UINT32_T in the code, define it to uint32_t or unsigned int.
Better autoconf check for uint32_t.
Happy Vimming,
Tony.
--
It is impossible to make anything foolproof because fools are so
ingenious.
--
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
