Hi Leif, I usually do one feature/fix per PR but do have multiple commits. Would it easier if we squash the commits into one and then create the PR?
On Tue, Aug 7, 2018 at 1:42 PM Leif Hedstrom <zw...@apache.org> wrote: > Hi, > > There are some serious shortcomings in Github when it comes to PRs with > multiple commits. It not only makes it difficult to know what commits are > associated with a PR, it also makes back porting / cherry-picking PRs from > master to an LTS branch really problematic. Essentially, there’s no easy > way (as far as I can tell) to find the upstream (master) commit IDs from > such a multi-commit PR. > > To make this less confusing, at least until Github fixes this brain damage > (if they can?), I’d like to propose that we have a strict policy for master > (and 9.0.x) that there’s is exactly one commit per PR. This doesn’t mean > that you shouldn’t break things up where it makes sense, it simply means > you’d want to make multiple PRs off your branch instead. > > Thoughts? > > — Leif > > P.s > If someone has a better idea, I’m willing to listen. But if you look at a > PR with multiple commits, Github only shows one of those commits in the > merge message. And the commit IDs it shows in the Commit tab is not the > upstream commit IDs, but rather the local repos commit IDs (which are > essentially useless for these purposes). -- pushkar
