cherry_picker fails on branch cleanup in non-main worktree

[serhiy-storchaka]

Every time when I run cherry_picker I get the following error:

🐍 🍒 ⛏
Usage: cherry_picker [OPTIONS] [COMMIT_SHA1] [BRANCHES]...
Try "cherry_picker -h" for help.

Error: Run state cherry-picker.state=CHECKING_OUT_DEFAULT_BRANCH in Git config is not known.
Perhaps it has been set by a newer version of cherry-picker. Try upgrading.
Valid states are: BACKPORT_PAUSED, UNSET. If this looks suspicious, raise an issue at https://github.com/python/core-workflow/issues/new.
As the last resort you can reset the runtime state stored in Git config using the following command: `git config --local --remove-section cherry-picker`

cherry_picker has been updated, it is 1.3.2.

Every time I need to run git config --local --remove-section cherry-picker to make cherry_picker working. This becomes annoying. Can it be fixed permanently?

[webknjaz]

@serhiy-storchaka this probably means that the previous run crashed while attempting to check out the default branch: https://github.com/python/cherry-picker/blob/39e8d6d/cherry_picker/cherry_picker.py#L218-L223. I don't think it's possible to safely assume states when the state machine gets stuck in an unexpected state. It's a sign that somebody needs to investigate how this may be happening.

[Jackenmen]

@serhiy-storchaka Is this still happening for you and if so, do you have any more details about this issue perhaps? Especially information about what could have caused the crash in the previous run as said above?
This issue has been open for 2 years and there isn't any information about how it can be reproduced so I was just wondering whether it could be time to close it 🤔

[serhiy-storchaka]

It is still happen to me every time I use cherry_picker. If the backport is successful, I still get an error:

$ cherry_picker --continue
🐍 🍒 ⛏
Backport PR URL:
https://github.com/python/cpython/compare/3.10...serhiy-storchaka:backport-cd44afc-3.10?expand=1
Traceback (most recent call last):
  File "/home/serhiy/bin/cherry_picker", line 8, in <module>
    sys.exit(cherry_pick_cli())
  File "/home/serhiy/.local/lib/python3.8/site-packages/click/core.py", line 1137, in __call__
    return self.main(*args, **kwargs)
  File "/home/serhiy/.local/lib/python3.8/site-packages/click/core.py", line 1062, in main
    rv = self.invoke(ctx)
  File "/home/serhiy/.local/lib/python3.8/site-packages/click/core.py", line 1404, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/home/serhiy/.local/lib/python3.8/site-packages/click/core.py", line 763, in invoke
    return __callback(*args, **kwargs)
  File "/home/serhiy/.local/lib/python3.8/site-packages/click/decorators.py", line 26, in new_func
    return f(get_current_context(), *args, **kwargs)
  File "/home/serhiy/.local/lib/python3.8/site-packages/cherry_picker/cherry_picker.py", line 639, in cherry_pick_cli
    cherry_picker.continue_cherry_pick()
  File "/home/serhiy/.local/lib/python3.8/site-packages/cherry_picker/cherry_picker.py", line 485, in continue_cherry_pick
    self.cleanup_branch(cherry_pick_branch)
  File "/home/serhiy/.local/lib/python3.8/site-packages/cherry_picker/cherry_picker.py", line 361, in cleanup_branch
    self.checkout_default_branch()
  File "/home/serhiy/.local/lib/python3.8/site-packages/cherry_picker/cherry_picker.py", line 226, in checkout_default_branch
    self.run_cmd(cmd)
  File "/home/serhiy/.local/lib/python3.8/site-packages/cherry_picker/cherry_picker.py", line 181, in run_cmd
    output = subprocess.check_output(cmd, stderr=subprocess.STDOUT)
  File "/usr/lib/python3.8/subprocess.py", line 415, in check_output
    return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
  File "/usr/lib/python3.8/subprocess.py", line 516, in run
    raise CalledProcessError(retcode, process.args,
subprocess.CalledProcessError: Command '('git', 'checkout', 'main')' returned non-zero exit status 128.

After that I need to perform cleanup manually:

• Check out the working branch (3.10 in this case): git checkout 3.10.
• Forcefully remove the backport branch: git branch -D backport-cd44afc-3.10. Just git branch -d does not work, because the merging was not completed.
• Clean up the Git config: git config --local --remove-section cherry-picker.

I have to do it every time, and it's a little annoying. I think it reduces my productivity.

[serhiy-storchaka]

I have separate worktrees for maintained branches and do backporting in the corresponding worktree. It may be related.

[Jackenmen]

Does this also happen if cherry-picker doesn't run into conflicts? I know that these are generally done automatically so you probably don't have to use cherry-picker in such cases but it might help narrow this down if you could check if it happens for such case as well.

[Jackenmen]

I have separate worktrees for maintained branches and do backporting in the corresponding worktree. It may be related.

Oh! Worktrees share a single git config so that could affect it in some way. Could you see if this happens when you enable worktree-specific git config:
https://git-scm.com/docs/git-worktree#_configuration_file

[serhiy-storchaka]

Since these are done automatically, I cannot remember when I used cherry_picker for backporting without conflicts last time.

[serhiy-storchaka]

Thank you. I will try this next time.

[serhiy-storchaka]

After setting separate configs by running git config extensions.worktreeConfig true I still get the same error.

cherry_picker tries to run git checkout main, and fails, because that branch has been checked out in a different directory. It should not do it, it should return to the branch that was checked out before.

[webknjaz]

@serhiy-storchaka could you craft a minimal reproducer?

[serhiy-storchaka]

Merge any PR into the main branch on GitHub. Update the checked out main branch locally. Create a separate worktree for a maintained branch. Go to this directory. Run cherry_picker. Resolve conflicts. Run cherry_picker --continue. I do not know whether it works with backporting without conflicts, but I think that it will get the same result.

It is common workflow.

[Jackenmen]

@serhiy-storchaka Alright, after your feedback, I've been able to make a fix for this in #61.
If there's something that you don't like about the behavior I explained in that PR's description, let me know.
If you would want this released on PyPI, I think you would have to contact Mariatta about it.

[serhiy-storchaka]

I do not know much about this code to make a competent review, but it looks cool! Thank you for such fast fix!