MQ merging

Peer Sommerlund peer.sommerlund at gmail.com
Sun Mar 2 17:38:28 CST 2008


On 02/03/2008, Jesse Glick <jesse.glick at sun.com> wrote:
>
> Jesse Glick wrote:
> > Probably MQ should save the original base parent for the _queue_
> > (i.e. `hg id -r qbase`) rather than an individual patch, because (1)
> > it makes no sense to save the parent of any patch which was not at
> > the top of the queue, (2) you might anyway reorder the queue before
> > rebasing (in which case any problems reapplying the patches is your
> > decision).
>
>
> I should amend this; better to save the qbase ID for each individual
> patch whenever it is created; pushed without fuzz or rejects; or
> refreshed. You may have a "stack" of patches which are in fact quite
> unrelated and which you worked on at different times, so it makes sense
> to remember for each one when it was known to apply cleanly.
>
> MQ could include this information in the series file, e.g.
>
> fix-some-problem.diff      abc123325ffb37227364298731aac
> another-rfe.diff           88f243ce880a7987c870987ee87d9
>
> (permitting a patch to have no specified qbase), or to retain
> bidirectional compatibility with older versions of MQ use a different
> file for the qbase mapping, or simply insert the information in an
> optional patch header:
>
> # Queue base: abc123325ffb37227364298731aac
> Description of patch.
> diff a/file b/file
> ....
>
> ("Parent node ID" is not an accurate description because the patch might
> apply only atop another patch. You want to record the queue base below
> all patches.)
>
>
> _______________________________________________
> Mercurial mailing list
> Mercurial at selenic.com
> http://selenic.com/mailman/listinfo/mercurial
>


Steve Borho has an mq-repo (http://hg.borho.org/mq-tortoisehg/) that builds
an installer on top of the mercurial repository. If I want to contribute to
his mq-repo, I have to pull it AND to locate the correct repository (in this
case hg-main) and changeset to use as qbase. The latter two steps is not
automated by Mercurial today. However, I can do it with

  hg qclone -p http://hg.borho.org/mq-tortoisehg/ http:/selenic.com/repo/hg
my-work
  hg up -R my-work -r <qbase> # qbase is unknown - so just pray that it is
tip

If the series file also stored the default path (in addition to qbase), and
qclone was extended to support this, then I could simply write
  hg qclone http://hg.borho.org/mq-tortoisehg/ my-work
and mercurial would automatically do
  hg qclone -p http://hg.borho.org/mq-tortoisehg/ http:/selenic.com/repo/hg
my-work
  hg up -R my-work -r <qbase> # qbase is the same as used by borho


Storing a single qbase (for the entire queue) would be fine for me. Although
I do use guards, I always have the same qbase. If I wanted to have several
qbases, I could make this happen using named branches in the mq-repo.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://selenic.com/pipermail/mercurial/attachments/20080303/544213c1/attachment.html 


More information about the Mercurial mailing list