how to rebase MQ patches

[Ondrej Certik]

Hi,

there was a question in:

http://code.google.com/p/sympy/issues/detail?id=608#c7

about how to rebase the MQ patches to the latest tip:

-------
> > I just tried to submit 4 patches (fix of #608, capital gamma function, ascii-art for
> > floor/ceiling, and misc changes to pprint tests), but got conflict problems
> (overlap). I just don't know what to do. Any hint? :)
>
> Sure, you need to rebase your patches to the latest tip. The mercurial generates the
> .rej files, that you can inspect and fix the problems. Or do you have some other problem?

Should I re-run "hg qrecord" commands and retype patches' descriptions
all over again
or is there some other clever way? Sorry, I'm really newbie to
Mercurial and SCM...
-------

So here is what I do (opinions -- kirill? :):

1) create the patches that apply cleanly in some revision
2) hg qpop -a; hg pull; hg up
3) hg qpush -a

does it apply cleanly? yes -- cool. No:

is the conflict easy to fix? If so, thenb I just look into the
generated .rej files and fix the repo by hand, then do "hg qrefresh"
and that's it.
If the conflict is difficult to fix:

4) hg qpop -a; hg up "number of the revision that worked";

5) hg push; hg qdelete -r qbase:qtip
6) hg merge tip

now merge the changesets using the powerful mercurial merge facility.

7) hg di -r revision without the patch:tip > /tmp/x

and we have the rebased patch in /tmp/x, so I for example do something like

8) hg qimport /tmp/x; hg qrefresh -e;

fix the description etc.

Then repeat the steps 5) to 8) with all patches.

Any comments welcome.

Ondrej

[Ondrej Certik]

One comment from myself -- it's ok if you submit patches, that apply
(cleanly!) to some recent revision. It doesn't have to be the very
latest one.
If the merge is trivial, the sympy developer with push access will do
it himself before pushing.

That's the power of distributed VCS -- you don't have to be still in
on guard and rebase all your patches to the latest tip. Once the patch
applies in some (recent) revision, it's usually just a matter of
seconds to rebase it to the latest tip, thanks to mercurial, and it's
a manual work that anyone can do, even if I didn't write the code in
the first place. In most cases.

Ondrej

[Roberto Nobrega]

Thanks, that helped a lot!

Fortunately my case was the easy one, and I think I got the idea. :)

Roberto.

[Kirill Smelkov]

On Wed, Apr 23, 2008 at 01:38:48AM +0200, Ondrej Certik wrote:
>
> Hi,
>
> there was a question in:
>
> http://code.google.com/p/sympy/issues/detail?id=608#c7
>
> about how to rebase the MQ patches to the latest tip:
>
> -------
> > > I just tried to submit 4 patches (fix of #608, capital gamma function, ascii-art for
> > > floor/ceiling, and misc changes to pprint tests), but got conflict problems
> > (overlap). I just don't know what to do. Any hint? :)
> >
> > Sure, you need to rebase your patches to the latest tip. The mercurial generates the
> > .rej files, that you can inspect and fix the problems. Or do you have some other problem?
>
> Should I re-run "hg qrecord" commands and retype patches' descriptions
> all over again
> or is there some other clever way? Sorry, I'm really newbie to
> Mercurial and SCM...
> -------
>
> So here is what I do (opinions -- kirill? :):

I too use something like this :)

> 1) create the patches that apply cleanly in some revision
> 2) hg qpop -a; hg pull; hg up
> 3) hg qpush -a
>
> does it apply cleanly? yes -- cool. No:

Yes, right now we have to use the trickery you are describing below, but
please see some remark at the end of this letter.

> is the conflict easy to fix? If so, thenb I just look into the
> generated .rej files and fix the repo by hand, then do "hg qrefresh"
> and that's it.
> If the conflict is difficult to fix:
>
> 4) hg qpop -a; hg up "number of the revision that worked";
>
> 5) hg push; hg qdelete -r qbase:qtip
> 6) hg merge tip
>
> now merge the changesets using the powerful mercurial merge facility.
>
> 7) hg di -r revision without the patch:tip > /tmp/x
>
> and we have the rebased patch in /tmp/x, so I for example do something like
>
> 8) hg qimport /tmp/x; hg qrefresh -e;

You don't need to 'hg diff > /tmp/x; hg qimport' --

'hg qimport -r rev' would do the same.

>
> fix the description etc.
>
> Then repeat the steps 5) to 8) with all patches.
>
> Any comments welcome.

By the way, there is a guy who is going to implement 'hg rebase' during
the SoC:

http://code.google.com/soc/2008/hg/appinfo.html?csaid=EC7D811E53CA98EF

--
Всего хорошего, Кирилл.

[Ondrej Certik]

I don't think that's gonna work -- you need to diff all changes
between the old revision without the patch and the tip. You can get
the changes
with "hg di -r old:tip", but with qimport it imports all the revisions
as distint patches, which is not what you want.

>
>
> >
> > fix the description etc.
> >
> > Then repeat the steps 5) to 8) with all patches.
> >
> > Any comments welcome.
>
> By the way, there is a guy who is going to implement 'hg rebase' during
> the SoC:
>
> http://code.google.com/soc/2008/hg/appinfo.html?csaid=EC7D811E53CA98EF

Things like this only show how seriously Mercurial is lagging behing
git. But hopefully it will improve soon enough.

Ondrej

[Patrick Mezard]

On Apr 23, 1:38 am, "Ondrej Certik" <ond...@certik.cz> wrote:
> If the conflict is difficult to fix:
>
> 4) hg qpop -a; hg up "number of the revision that worked";
>
> 5) hg push; hg qdelete -r qbase:qtip
> 6) hg merge tip
>
> now merge the changesets using the powerful mercurial merge facility.
>
> 7) hg di -r revision without the patch:tip > /tmp/x
>
> and we have the rebased patch in /tmp/x, so I for example do something like
>
> 8) hg qimport /tmp/x; hg qrefresh -e;
>
> fix the description etc.
>
> Then repeat the steps 5) to 8) with all patches.

I know the builtin way is more complicated than it should be but why
not use it ?

hg qpop -a
hg up "number of the revision that worked"

hg qpush -a
# Save the queue here for reference, it gives you a name like
"patches.N"
hg qsave -ce
hg up -C "revision where to rebase from"
# Push until all patches are rebased (or qpush -am), merging them if
necessary
hg qpush -m
# Cleanup current and reference queue
hg qpop -a
hg qpop -a -n patches.N
# At this point, you can get rid of .hg/patches.N
# And now your new rebased queue is here:
hg qpush -a