> On Aug 7, 2018, at 16:48, Jason Kenny <jke...@oath.com.INVALID> wrote: > > 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
Yes that’s works. But you can’t do the inverse and look at a PR and get all the commit IDs if there is more than one. It only shows the first one. And that makes the RM work very difficult . — Leif > > 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.
