Add machete.github.retrieveByAuthor and machete.gitlab.retrieveByAuthor git config keys

[PawelLipski]

Summary

• Add machete.github.retrieveByAuthor / machete.gitlab.retrieveByAuthor: when set, PR/MR-listing commands download open PRs/MRs by author (GitHub GraphQL search / GitLab author_username filter) instead of every open PR/MR in the repository.
• By default (and with --mine) that author is the current user; --by=<user> selects a different author, and chain reconstruction walks that author's PRs rather than the current user's.
• --all still downloads every open PR/MR regardless of the key.

This makes annotating and traversing one's own PRs feasible in repositories with hundreds or thousands of open PRs, at the cost of not discovering PRs opened by other users when traversing mixed-author chains.

Test plan

• Unit tests for checkout-prs/checkout-mrs with the key: --all, --by, --mine, and explicit PR/MR number
• Unit tests for update-pr-descriptions/update-mr-descriptions with the key: --related, --by, --all, --mine
• Unit tests for anno-prs/anno-mrs with the key (and missing current user on GitHub)
• Live-tested on VirtusLab/git-machete: anno-prs fetched only PawelLipski; checkout-prs --by=be-student fetched only be-student (no second PawelLipski fetch) and checked out Add advice setting for pull request creation from forks #1774/Reuse the resolved GitHub repository path after a redirect #1776; --mine fetched only PawelLipski

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.67%. Comparing base (0c1928c) to head (4d2b5e6).

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #1746      +/-   ##
===========================================
- Coverage    98.68%   98.67%   -0.01%     
===========================================
  Files           45       45              
  Lines         5384     5452      +68     
  Branches       979      991      +12     
===========================================
+ Hits          5313     5380      +67     
  Misses          43       43              
- Partials        28       29       +1     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[sjbarag]

Thanks for implementing this @PawelLipski - it'll be super helpful for $dayjob use. Is there anything I can do to help this get closer to merging?

[PawelLipski]

Thanks for implementing this @PawelLipski - it'll be super helpful for $dayjob use. Is there anything I can do to help this get closer to merging?

For clarity, what's $dayjob here? 😅 are you a human? 🧐
Also, could you describe your specific case where this will be useful? I'm on the fence whether to actually add this feature 🤔

[sjbarag]

Thanks for implementing this @PawelLipski - it'll be super helpful for $dayjob use. Is there anything I can do to help this get closer to merging?

For clarity, what's $dayjob here? 😅 are you a human? 🧐 Also, could you describe your specific case where this will be useful? I'm on the fence whether to actually add this feature 🤔

Hehe, sorry, old-internet habits. I work at Netflix. The monorepo I do most of my work in has 932 PRs open right now¹, and git machete github anno-prs takes ~17 seconds. Not the end of the world, but a bit of a flow-breaker to wait that long. At peak, my open PR count was probably… 6? 10? 🤷

To be more specific: I'm using git machete for some manual PR stacking and as a running ledger of which PRs I've got open, which I've merged, etc. Obv gh pr list --author '@me' does that too, but machete makes the bulk-rebasing process easier. Especially for shallow PR trees (think 3-4 independent changes that can merge in any order).

All that's to say: a machete.github.retrieveOnlyMyPullRequests toggle would be nice, but I recognize it's edge-casey and maybe not worth the maintenance cost long-term!

Footnotes

1. Most of those PRs are old. I suspect listing PRs created in the last 30-60 days would cut the number of required pages to < 3, but haven't checked. ↩

[PawelLipski]

Okay! I'll probably get that shipped then - I'll use retrieveByAuthor key name instead (as we need to handle --by case cleanly as well - only retrieve PRs/MRs by that author)