This is a regression from Mercurial 1.9.3. Test case: $ cat >> $HGRCPATH <<EOF > [extensions] > rebase= > EOF $ hg init a $ cd a $ touch one $ hg ci -A -m one adding one $ hg update null 0 files updated, 0 files merged, 1 files removed, 0 files unresolved $ hg branch br-anch marked working directory as branch br-anch $ touch two $ hg ci -A -m two adding two $ hg update default 1 files updated, 0 files merged, 1 files removed, 0 files unresolved $ hg rebase --base br-anch saved backup bundle to * (glob) Starting from cset b12362ab13e7, the output is: $ hg rebase --base br-anch abort: unknown revision 'br'! [255] changeset: 15269:b12362ab13e7 user: Matt Mackall <mpm@selenic.com> date: Sat Oct 15 12:57:47 2011 -0500 summary: rebase: allow revsets for source and base args
rebase --base now take a revset expression (as more and more place in mercurial). To get the same result, you now need to use: rebase --base 'max(branch("br-anch"))'
Thanks for the workaround. However, the new behaviour is still inconvenient for my team. We regularly use JIRA issue ids (which contain dashes) as branch names. I believe this is a defect, since "rebase --base" seems to accept ONLY revsets, whereas the other commands seem to search by name and then fall back to using revsets. For example, "hg update br-anch" and "hg revert --all -r br-anch" both work.
Agreed, this does qualify as a regression.
Fixed by http://selenic.com/repo/hg/rev/e4fc0f0b4f7e Steven Brown <StevenGBrown@gmail.com> rebase: reinstate old-style rev spec support for the source and base (issue3181) (please test the fix)
--- Bug imported by bugzilla@serpentine.com 2012-05-12 09:26 EDT --- This bug was previously known as _bug_ 3181 at http://mercurial.selenic.com/bts/issue3181