I think in most cases what Abe mentioned makes sense. That's the easiest way to see the changes between updates to a PR.
The tool Camille linked to manages the cherry-pick process for the committer so that's handled no problems. Usually. The only issue is when a PR can't be merged on the the branch head because of a conflict. I typically need the PR requester to rebase on the head at that point. Although even in that case keeping the separate commits, and not squashing, is probably better. Regards, Patrick On Fri, Dec 1, 2017 at 8:29 AM, Camille Fournier <[email protected]> wrote: > You can find details here: > https://cwiki.apache.org/confluence/display/ZOOKEEPER/Committing+changes > > C > > On Fri, Dec 1, 2017 at 1:25 AM, Andor Molnar <[email protected]> wrote: > > > Hi, > > > > @afine raised this on my latest PR: > > "going forward it would be great if you didn't squash your commits when > > updating your pr in response to comments (I'm guilty of doing this too), > i > > think the pr merge script handles that plus it is more difficult to see > > exactly what you changed in response to the comments." > > > > I was under the impression that keeping one single commit in PRs makes > > commiters' life a lot easier when cherry-picking. Also single commit > merges > > keep the git log cleaner on the master branch which is also a plus. > > > > I won't do fixups going forward to make the reviews easier, just curious > > how does it work behind the scenes? > > > > Cheers, > > Andor > > >
