Thomas Arendsen Hein <> wrote:
> * Ling, Xiaofeng <xiaofeng.ling@xxxxxxxxx> [20050830 08:38]:
> Merge changesets are mostly uninteresting. It seems that you think
> 'hg merge' is something that it isn't. With merge you don't move
> changesets around, but you link changesets together in a new way.
> You can do this: Use 'hg co -m' to merge the heads and after this 'hg
> revert -r tip' to make the working directory look like the unmerged
> tip was before. Now commit.
I'm confused about this, if use hg revert -r tip, the current working directory
will become tip revision, won't that lose all the merge change?
>>> Now the good news: You can do many things you describe here with the
> Yes, because it doesn't add changesets with your local changes, but
> keeps a set (or queue) of patches against the unmodified tree.
>
>> BTW, seems 0.6c doesn't support extension yet. I had to use the
>> latest hg.
>
> I'd recommend to use the latest hg if you want to use mq, but there
> are older versions of mq in the 'old' subdirectory which may work
> with older hg versions.
I had some try, but seems I've not understood all the processing yet.
I do:
hg qinit
copy /a.patch .hg/patches
edit .hg/series and add a.patch
hg qnew a.patch
now seems the patch became a new revision.
then
hg qrefresh
error, python trace
hg strip
error, python trace
seems I need to study more.
Thank you.
|
