The Mercurial way of doing it?

[Christian Boos]

Philip Pemberton wrote:
>
> Christian Boos wrote:
>> However, there's a caveat for the specific scenario you're interested 
>> in, as you'll end up with:
>>
>>            |---------[release-v2] o----o[cust-bike_dock]
>> [master]o--|                          /
>>            |---------[release-v1] ---
>>
>> i.e. the first rebased changeset from cust-bike_dock will be a merge 
>> changeset.
>
> Not if you do it like this:
>
> hg rebase --base <B> --dest <D>
>
> Where: <B> = the rev of the code to rebase (cust-bike_dock's revtag)
>        <D> = the rev of the new base (release-v2's revtag)
>
> I tried it on a fairly simple test repo and it worked fine, and left 
> me with something like this:
>
>            |---------[release-v2]o----o[cust-bike_dock]
> [master]o--|
>            |---------[release-v1]

I don't think so, I'm pretty confident you also had the [release-v1] 
changes rebased on top of [release-v2]. That's what -b is supposed to 
do: "-b rev" finds the "base" of the changesets to rebase, i.e. the 
oldest ancestor of rev which is not also an ancestor of the target rev.

Admittedly the help is not crystal clear about that:
 "-b --base          rebase from the base of a given revision"
but what's the base?

>
> The exact command I used was:
>   hg rebase --keepbranches -b 3 -d 6

And the exact reproduction recipe?

Check this one, for example:

mkdir test1950
cd test1950
hg init
echo FILE > file
hg ci -Am start -d '0 0' -u me
echo V1 > file
echo FILE >> file
hg ci -m v1 -d '0 1' -u me
echo CUSTOM >> file
hg ci -m CUSTOM -d '0 2' -u me
hg up -c 0
echo V2 > file
echo FILE >> file
hg ci -m v2 -d '0 2' -u me
cd ..

hg glog -R test1950 --style=compact

@  3[tip]:0   c6e93201bb42   1969-12-31 23:59 -0000   me
|    v2
|
| o  2   60c1d589062f   1969-12-31 23:59 -0000   me
| |    CUSTOM
| |
| o  1   22b0d35c16e8   1969-12-31 23:59 -0000   me
|/     v1
|
o  0   b96560c07228   1970-01-01 00:00 +0000   me
     start


hg clone test1950 test1950-s
hg rebase -R test1950-s -s 60c1d589062f -d c6e93201bb42
hg glog -R test1950-s --style=compact

@    3[tip]:2,1   91c284d40d3d   1969-12-31 23:59 -0000   me
|\     CUSTOM
| |
| o  2:0   c6e93201bb42   1969-12-31 23:59 -0000   me
| |    v2
| |
o |  1   22b0d35c16e8   1969-12-31 23:59 -0000   me
|/     v1
|
o  0   b96560c07228   1970-01-01 00:00 +0000   me
     start


hg clone test1950 test1950-b
hg rebase -R test1950-b -b 60c1d589062f -d c6e93201bb42
hg glog -R test1950-b --style=compact

@  3[tip]   6a77bde81e62   1969-12-31 23:59 -0000   me
|    CUSTOM
|
o  2   e4dd676388b2   1969-12-31 23:59 -0000   me
|    v1
|
o  1   c6e93201bb42   1969-12-31 23:59 -0000   me
|    v2
|
o  0   b96560c07228   1970-01-01 00:00 +0000   me
     start


As I said, by specifying -b 60c1d589062f, rebase finds by itself the 
actual changeset to use for the source. In this case, this was 
22b0d35c16e8 which got rebased as e4dd676388b2.

In the bts on issue1950, I proposed to have an extra switch to rebase, 
call it "--detach" or "--linear", that would allow you to get rid of 
this "external" parent (22b0d35c16e8 in this case).

i.e. an hypothetical command:

hg rebase -R test1950-b -b 60c1d589062f -d c6e93201bb42 --detach

would give:

@    3[tip]:2,1   91c284d40d3d   1969-12-31 23:59 -0000   me
|     CUSTOM
|
o  2:0   c6e93201bb42   1969-12-31 23:59 -0000   me
|    v2
|
| o  1   22b0d35c16e8   1969-12-31 23:59 -0000   me
|/    v1
|
o  0   b96560c07228   1970-01-01 00:00 +0000   me
     start


As this is what people usually expect to happen, maybe that could even 
become the default and we could have an option (--keepparent) to fall 
back to the current behavior. But how the current behavior in this 
situation is useful at all remains to be clarified...

-- Christian