Andy Parkins <andyparkins@xxxxxxxxx> writes:
> This is an unreasonable thing to expect a version control
> system to be able to do ...
I do not necessarily think so. If you have this:
o---X
/
---a---o---o---o
\ \
-o---o---M---Y
it is perfectly reasonable to want to have this:
o---X---o---o---o
/ \ \
---a o---o---M'--Y'
when you say "rebase --onto X a Y".
However, you have to be careful. The thing is, you do not want
to 'rebase' a merge if the other branch came from somewhere not
under your control. If 'a', 'o', 'X', 'Y' and 'M' are under
your control, and 'x' are from somebody else's tree in the
following picture:
o---X
/
---a---o---o---o
\ \
x---x---x---M---Y
and if you say "rebase --onto X a Y", it is not useful to rebase
'x' when you want to rewrite your history. They are somebody
else's history, and other people might have got it already, too.
Even if you _could_ rebase them, you would rather not.
And this is true even if 'x' are your own. You might have
pushed out these 'x' to public repo although you haven't pushed
out 'M', 'Y', 'o' nor 'X', and would want to rebase the
still-private part to clean up the history before publishing.
In such a case, you would want to end up with something like
this:
o---X---o---o---o
/ \
---a .-------M'--Y'
\ /
x---x---x
This kind of rebase should be doable but you would need to tell
the tool which parents of merges you would want to rebase and
which ones you do not want to touch but recreate the merge by
merging with your rebased branches again. In the above 'ideal',
picture, three 'o's have been rebased, and then merge 'M' was
recreated from the rebased rightmost 'o' and the rightmost 'x'
in the original picture.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html