Skip to content

Cherry_picker should checkout original branch. #6

Closed
@terryjreedy

Description

@terryjreedy

I ran "py -3 -m pip install cherry_picker" and all went well.
In my 3.7 worktree, I ran "py -3 -m cherry_picker f3e8209 3.6" and with one more click, it produced python/cpython#2321. Great.

The only problem, which I mentioned before on another issue, is that on Windows, checking out 3.6 to prepare the PR irreversibly touches most .c files, so that a subsequent rebuild recompiles most C files. This time I made sure that cherry_picker is the culprit by running a rebuild immediately before and after cherry_picker. Starting in my 3.6 worktree would be worse because cherry_picker would checkout master and cause the same rebuild issue, plus leave the wrong branch checked out.

Request and suggestion. Run git status and capture the first line of the response: "On branch xyz". If is 'master', '3.6, '3.5', or '2.7', store it and execute f'git checkout {xyz}' instead of hard-coding master as the return checkout. Or just store xyz whatever it is and check it back out, so cherry_picker restores the status quo whatever it was.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions