Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upGitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
[spike] Infer PR associated with current branch #1719
Conversation
Search PRs in current and parent repo for one that targets the current branch name and owner.
BranchModel is always constructed using a local branch so IsRemote is never true (it is passed repo.Head not repo.Remote.Head).
LocalBranchModel represents the local branch of a LocalRepositoryModel.
ILocalBranch includes extra information that is available when a branch is from a local repository.
We're only interested in PRs that target the parent (upstream) or owner (current) repo.
|
We're planning to warn the user with a call-out notification (see #2026) rather than having alternative logic to choose the default remote when "origin" isn't defined. This will make it obvious what's going on and avoid any magic. |

Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.

This is a spike to experiment with infering the PR associated with the current branch.
What this PR does
TODO
Use
associatedPullRequestsproperty ofref.Findings
There can be multiple PRs that use the same branch as their HEAD. We could up with a conservative strategy that minimizes false positives but that still works in most cases?
For example, say a user creates a PR using their
masterbranch. They probably won't want this PR associated with theirmasterbranch forever!There are attributes associated with a PR that we could take into account to infer when a PR is likely stale and shouldn't be automatically associated with the current branch. For example:
Fixes #1591