cherry_picker has recently grown support for prefixed version branches
(like stable-2.6). The --continue support had a bug with those branches
where it wouldn't account for the fact that those branches could have
extra dashes in them and thus mixing branch name with sha.

This commit should fix those situations.

@abadger You need to take into account case when a user might run --continue from a different branch:

=================================== FAILURES ===================================
______________________ test_get_base_branch_without_dash _______________________
    def test_get_base_branch_without_dash():
        cherry_pick_branch ='master'
>       result = get_base_branch(cherry_pick_branch)
cherry_picker/test.py:43: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
cherry_pick_branch = 'master'
    def get_base_branch(cherry_pick_branch):
        """
        return '2.7' from 'backport-sha-2.7'
        """
>       prefix, sha, base_branch = cherry_pick_branch.split('-', 2)
E       ValueError: not enough values to unpack (expected 3, got 1)
cherry_picker/cherry_picker.py:425: ValueError
===================== 1 failed, 27 passed in 0.35 seconds ======================

Ah... I thought rpartition traced back in that case too but I see now it always returns a three tuple.

I can replicate the previous behaviour here but I'm not sure... is that actually sensible behaviour? From where it's being called, I think that this would cause other bugs.

I've pushed a change to the test cases which removes the "no_dash" test and adds one for "dashes in the base branch".

I can replicate the previous behaviour here but I'm not sure... is that actually sensible behaviour? From where it's being called, I think that this would cause other bugs.

Git itself is a very stateful tool, so it's expected that when you rely on it there's some restrictions.

When running cherry_picker --continue we count on being able to get
certain information from the branch's name which cherry_picker
constructed earlier.  Verify as best we can that the branch name is one
which cherry_picker could have constructed.

Relies on the changes here: python#265
(which does the work of one of the validations)

My question doesn't come from what git does; it comes from what cherry-picker is doing with this branch name. AFAICT, the branch name has to be one that we created (with the three dashes), otherwise the present code will fail. So it seems like the current test that no dashes works is testing something that we'll never want the code itself to do.

When running cherry_picker --continue we count on being able to get
certain information from the branch's name which cherry_picker
constructed earlier.  Verify as best we can that the branch name is one
which cherry_picker could have constructed.

Relies on the changes here: python#265
(which does the work of one of the validations)

Sorry for the delay in responding to this! 🙇‍♀️
The original implementation was based on CPython's branch names that doesn't include dashes, so it didn't handle ansible's situation.
Thanks for catching and fixing this!