Skip to content

Conversation

@aaron-skydio
Copy link


Description

Currently, the pull request selected for a commit is the most recently updated one. As mentioned in #1913, this is not always desired, for example when a feature merges to one branch, and then that branch is merged into additional branches.

This adds a setting to order by updated or created time, ascending or descending. It preserves the other behavior, of preference based on owner and merged status.

Checklist

  • I have followed the guidelines in the Contributing document
  • My changes follow the coding style of this project
  • My changes build without any errors or warnings
  • My changes have been formatted and linted
  • My changes include any required corresponding changes to the documentation (including CHANGELOG.md and README.md)
  • My changes have been rebased and squashed to the minimal number (typically 1) of relevant commits
  • My changes have a descriptive commit message with a short title, including a Fixes $XXX - or Closes #XXX - prefix to auto-close the issue that your PR addresses

…given commit

Currently, the pull request selected for a commit is the most recently
updated one.  As mentioned in gitkraken#1913, this is not always desired, for
example when a feature merges to one branch, and then that branch is
merged into additional branches.

This adds a setting to order by updated or created time, ascending or
descending.  It preserves the other behavior, of preference based
on owner and merged status.
@nocnokneo
Copy link

This would solve our GitOps workflow where we first merge changes to main then later use a PR approval process to merge main -> deploy/prod. Those PRs targetting deploy/prod, deploy/test, etc are not interesting.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants