Backport branch deleted even if push fails
Chưa có ai nhận issue này.
- Ngôn ngữ chính
- Python
- Star
- 65
- Fork
- 47
- Merge trung bình
- 5 phút
- Pull request đã merge (30 ngày)
- 1
Mô tả
As @warsaw discovered the hard way on python/cpython#101024 , if pushing the branch to the selected (or default) remote fails for any reason (e.g. attempting to push to upstream instead of origin, as happened here), the branch is deleted anyway instead instead of issuing a clear error message and existing with it intact. This results in potentially loosing a large amount of hard, tedious work manually resolving backport conflicts (unless the user is a Git expert who knows how to recover it via git reflog), and is a very frustrating and unfriendly user experience.
Full error output from Barry
% cherry_picker --continue
git switch🐍 🍒 ⛏
Failed to push to origin ☹
remote: error: GH006: Protected branch update failed for refs/heads/backport-49cae39-3.10.
remote: error: You're not authorized to push to this branch. Visit https://docs.github.com/articles/about-protected-branches/ for more information.
To github.com:python/cpython.git
! [remote rejected] backport-49cae39-3.10 -> backport-49cae39-3.10 (protected branch hook declined)
error: failed to push some refs to 'github.com:python/cpython.git'
branch backport-49cae39-3.10 has been deleted.
Backport PR:
[3.10] gh-101021: Document binary parameters as bytes (GH-101024).
(cherry picked from commit 49cae39ef020eaf242607bb2d2d193760b9855a6)
Co-authored-by: Bob Kline <bkline@users.noreply.github.com>
If pushing fails, the PUSHING_TO_REMOTE_FAILED state is set https://github.com/python/cherry-picker/blob/main/cherry_picker/cherry_picker.py#L407, but then push_to_remote just returns and the branch is deleted regardless of the state https://github.com/python/cherry-picker/blob/main/cherry_picker/cherry_picker.py#L521 . As far as I can tell, setting the PUSHING_TO_REMOTE_FAILED state has no effect and cherry-picker just continues and terminates normally regardless.
I'm not sure the best way to fix this within Cherry_Picker's error handling and UX design, but the most obvious solution is to just have it raise e.g. RuntimeError and exit instead. There may be other situations where this happens as well, so it might be worth investigating any other known failure codepaths further.
As a sidenote I also discovered after much trial and error that you need to pass --no-auto-pr and --pr-remote upstream every time you call cherry picker --continue to get it to work, instead of it being stored in .gitconfig. This is very unintiuitve, and could also potentially lead to this error as well.
Also, calling --dry-run --continue in the middle of a cherry pick to see what it would do next completely borks things, and requires wiping the config and starting over to recover.
Hướng dẫn đóng góp
Chưa lập chỉ mục được hướng dẫn đóng góp cho kho mã nguồn này
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Hướng nghiên cứu
Bắt đầu trong cherry_picker/cherry_picker.py, tại phần xử lý PUSHING_TO_REMOTE_FAILED gần các dòng 407 và 521, sau đó lần theo push_to_remote và luồng tiếp tục. Tái hiện một lần push thất bại trong khi dùng --continue và xác minh rằng nhánh vẫn nguyên vẹn, đồng thời lệnh thoát với một lỗi rõ ràng thay vì hoàn tất bình thường.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Đánh giá
- Công nghệ
- git, python
- Lĩnh vực
- cli, tooling
- Loại issue
- Lỗi
- Độ khó
- 3/5
- Thời gian dự kiến
- 1-2 ngày
- Mức độ hoạt động
- Ít trao đổi
- Độ rõ ràng
- Khá rõ ràng
- Mức phù hợp với người mới
- 55/100