I am just odd... but I search on the commit message. ie the one value in the top of the PR page. It has always worked for me.. except when ( which we generally don't have) we have a lot of commits with the same message. In these cases, we get a set of commits back and I can check which one I want
Jason On Tue, Aug 7, 2018 at 5:04 PM Alan Carroll <solidwallofc...@oath.com.invalid> wrote: > I agree this is ultimately because github has a real problem in their user > interface, that the knowledge of the destination branch for a merged PR are > dumped rather than preserved in the PR records. This leaves us with a > choice between several (IMHO) unpleasant alternatives - struggling with > multi-commit PRs as we do now, only one commit per PR, or merge commits. > Which is the least worst? > > I'm basically OK with the one commit per PR, except that I've had simple > PRs hang out for a month or so without review or comment, so something like > #4029 could take half a year to get in, and that's just one piece of a > larger work. That's kind of painful. There's also the problem that I get > negative feedback for PRs that don't have an immediate and obvious use. > That's problematic if the usage is 2 or 3 PRs in the future, or like #4029 > where the final commit that ties all the pieces together is 7 commits down. > > Overall, I would tend toward keeping rebase merges for PRs with 1 commit > and using merge commits for multi-commit PRs. The counter argument is this > is too complex a procedure for our community. >
