[openstack-dev] [tc][all] A culture change (nitpicking)
cboylan at sapwetik.org
Wed May 30 15:42:45 UTC 2018
On Wed, May 30, 2018, at 8:13 AM, Zane Bitter wrote:
> On 30/05/18 00:52, Cédric Jeanneret wrote:
> >> Another issue is that if the original author needs to rev the patch
> >> again for any reason, they then need to figure out how to check out the
> >> modified patch. This requires a fairly sophisticated knowledge of both
> >> git and gerrit, which isn't a problem for those of us who have been
> >> using them for years but is potentially a nightmarish introduction for a
> >> relatively new contributor. Sometimes it's the right choice though
> >> (especially if the patch owner hasn't been seen for a while).
> > hm, "Download" -> copy/paste, and Voilà. Gerrit interface is pretty nice
> > with the user (I an "old new contributor", never really struggled with
> > Gerrit itself.. On the other hand, heat, ansible, that's another story :) ).
> OK, so I am sitting here with a branch containing a patch I have sent
> for review, and that I need to revise, but somebody else has pushed a
> revision upstream. Which of the 4 'Download' commands do I use to
> replace my commit with the latest one from upstream?
> (Hint: it's a trick question)
> Now imagine it wasn't the last patch in the series.
> - ZB
> (P.S. without testing, I believe the correct answers are `git reset
> --hard FETCH_HEAD` and `git rebase HEAD~<patch_depth> --onto FETCH_HEAD`
We do have tools for this and it is the same tool you use to push code to gerrit. `git review -d changenumber` will grab the latest patchset from that change and check it out locally. You can use `git review -d changenumber,patchsetnumber` to pick a different older patchset. If you have a series of changes things become more complicated. I personally like to always operate against leaf most change, make local updates, then squash "back" onto the appropriate changes in the series to keep existing changes happy.
Yes, this is complicated especially for new users. In general though I think git review addresses the simpler cases of I need to use latest version of my change. If we use change series as proposed in this thread I think keeping the parent of the child changes up to date is going to be up to the more experienced nit picker that is addressing the minor problems and not the original change author.
More information about the OpenStack-dev