geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nabarun Nag <>
Subject Re: what is the best way to update a geode pull request
Date Fri, 31 May 2019 20:43:56 GMT
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.


On Fri, May 31, 2019 at 1:32 PM Helena Bales <> 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 <>
> 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.
> >

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message