Skip to content
Snippets Groups Projects
user avatar
Pierre-Yves David authored
Before this patch, `hg pull --rebase` would be a strict sequence of `hg pull`
followed by `hg rebase` if anything was pulled.

Now that rebase pick his default destination the same way than merge, than
`hg rebase` step would abort in the case the repo already had multiple anonymous
heads (because of the ambiguity). (changed in fac3a24be50e)

The intend of the user with `hg pull --rebase` is clearly to rebase on pulled
content. This used to be (mostly) enforced by the former default destination for
rebase, "tipmost changeset of the branch" as the tipmost would likely a
changeset that just got pulled. But this intended was no longer enforced with
the new defaul destination (unified with merge).

This changeset makes use of the '_destspace' mechanism introduced in the previous
changeset to enforce this.

This partially fixes issue5214 as no change at all have been made to the new
handling of the case with bookmark (unified with merge).
261c2537
History
Name Last commit Last update