Hi Sandipan. You are correct, except that I would say you don't need to force push, just regular push. If I were at the head of a branch I wanted to (re)upload to gerrit, I would run:
git push origin HEAD:refs/for/develop Gerrit will look at the Change-Id field in the commit message and use that to identify reviews. If one already exists, it will create a new patchset version (you can look at and compare them in the review UI if you like), and if it doesn't it will make a new review. In the output of the git command it will tell you which ones are new and which ones are updated if you're curious. While it can be mildly disorienting clicking around a series where the ordering of reviews has changed (gerrit tries to go off of the patchset version you're currently looking at), it has no problem keeping track of everything. Gabe On Wed, Feb 24, 2021 at 10:18 PM Sandipan Das <sandi...@linux.ibm.com> wrote: > Hello Boris, Gabe, > > I think I now have a good amount of changes to address from the initial > posting of the patch series. In case of mailing list based reviews, we > would typically post the whole series again with a V2 tag but I guess > Gerrit tracks changes based on Change-Id. > > So as long as the Change-Id is preserved, force pushing the branch with > revised patches will upload the new revision to Gerrit while still > preserving all of the historical data such as review comments, etc. > Is this correct? > > I am also planning to add a new patch that splits makeCRField() into > signed and unsigned variants (like Gabe suggested) and that would now > be the first patch of the series. Can that create any problems? > > > - Sandipan >
_______________________________________________ gem5-dev mailing list -- gem5-dev@gem5.org To unsubscribe send an email to gem5-dev-le...@gem5.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
