In my opinion, I am okay will multiple commits within a PR. But please do squash them to a single commit when it is pushed to develop. This helps us a ton if it is single commit. - bisect operations are easier when it is a single commit during major failure analysis. - cherrypick is easier when it is one commit.
I even don’t prefer merge commit messages : - none of the big ASF projects do it. - visualizing on tools is bit skewed. - difficult to analyze failures . I would like to reiterate Dan’s statement on emphasis on people and empathy over blanket process and rules. Regards Naba On Fri, May 31, 2019 at 1:32 PM Helena Bales <hba...@pivotal.io> wrote: > +1. I would guess that it is the checklist as part of the PR that is > confusing people. > > The other reason that history gets rewritten is when force pushing after a > rebase. While fast-forwarding is necessary on occasion, this can be > accomplished without rewriting history by using a merge. > > As part of our document on making PRs, we should include instructions on > how to handle the situation where fast-forwarding is necessary, explicitly > discourage the use of merges and force-pushes once a PR has been opened, > and some guidelines regarding the appropriate number of commits when the PR > is initially opened. Once we have these guidelines, it would be helpful to > link to them from the PR checklist that we currently have, and rework the > checklist so that it is in line with our desired process. > > On Fri, May 31, 2019 at 1:20 PM Darrel Schneider <dschnei...@pivotal.io> > wrote: > > > Something I have noticed is that often when I have requested changes be > > made to a pull request is that the changes are force pushed ask a single > > commit to the pr. I would actually prefer that the changes show up as a > new > > commit on the pr instead of everything being rebased into one commit. > That > > makes the history of the pr easier to follow and make it easy to see what > > has changed since the previous review. What do others think? Have we done > > something that makes contributors think the pull request has to be single > > commit? I know the initial pull request is supposed to be but from then > on > > I'd prefer that we wait to squash when we merge it to develop. > > >
