If I have multiple patch set versions for one change in Gerrit, it seems like I can only submit the latest patch set version (because only that one has the necessary button). Is there an easy way to instead submit one of the old patch set versions of the same change, using only my web browser on that Gerrit instance?
I know that I can fetch the wanted version of the patch set from my git client and push it as yet another new patch set version on top, but I would like to avoid having identical patch set versions multiple times in the review and discussion around it.
No, sorry, this is not currently possible. The design assumes that the most recent patch set is the one developers will review and test, and as such older patch sets can not be submitted. They also can not be reviewed/verified. If you want to use an older version of a patch set, you must re-submit it to make it the most recent patch set. To avoid no new changes error do git commit --amend and git will create a new sha1, which will be happily accepted by Gerrit as a new patch set.
There is no proper way to do this using only Gerrit UI. Cherry-pick the specific "patch set" of the "change list" (e.g. if there are 15 patch sets in a Change List and want to revert back to patch set #8). Get the cherry-pick command from Gerrit UI for the required patch set.
Run that cherry-pick command, and use git commit --amend, then push your change. It will generate new patch set (for above example #16).
The only way I could do this was as follows (from the change refspec assuming you are in Gerrit revision "<change-no>/3" and want to go back to "<change-no>/1").
git review -d <change no>,1
git commit --amend # modify something in the commit message
git review # resubmit the changes, will submit to rev 1
Related
Is there a way to delete a patch set in Gerrit? I accidentally pushed a file with a password in it to my change. I removed the file in another patch set but the file is still visible in the patch set history. I attempted to find a way to delete that particular patch set but the only thing I could find on how to do this was the following documentation...
https://gerrit-documentation.storage.googleapis.com/Documentation/2.8/cmd-review.html
which shows a delete option but that option is no longer available in later versions.
I ended up just checking out the latest patch set, creating a new branch, deleting the current change in gerrit and pushing the change from the new branch which removes the old patch sets but it seems a bit cumbersome.
No, you can't delete a patch set in Gerrit, but it's possible to delete the whole change. If you do not see the "Delete change" option, it's because you don't have permission to do that.
There are two permissions to control this, see the Gerrit documentation:
Delete Own Changes
Delete Changes
Last but not least, in these cases, it's better to simply change the password instead of trying to remove it from the repository. It's better safe than sorry.
A colleague sent me a Gerrrit code review "draft" (I suppose via "refs/drafts/master" instead of "refs/for/master") and then left on holiday. Without downloading the patch and submitting it myself, how can I promote his draft to a full regular code-review so I can approve it & submit it for merging?
I think this is a similar question, but it's for git-review, not Gerrit. Also I'm interested in doing it from the Gerrit web GUI if at all possible. And I don't see a "Publish" button on my Gerrit web GUI for that draft. (And currently it doesn't say anything about merge conflicts, as long as I hurry....)
If I click on the "Patch Sets" link in the top right of the GUI, this is what I see:
In the top left it says "Change 58358 - Draft", and in the middle of the window it shows this:
Only the change owner can publish a draft patch set. Using the UI's cherry-pick option as described in other answers won't work because the cherry-pick implementation preserves the draft status on the new change or patch set.
As far as I know the only way to force the change into NEW state is to manually download the commit and push a new patch set using refs/for/master instead of refs/drafts/master.
Note that if you're not rebasing the change onto a new parent at the same time, you might need to slightly edit the commit message to make gerrit accept it. Otherwise it'll reject with no new changes.
If your colleague add you as reviewer, you can. You can cherry-pick this commit.
Click on download link at the right-top corner, and there are aliases for commands above.
But as you updated your question, you don't want to check out and manually push or cherry pick to master branch. You can use cherry-pick\merge button on ui, if you are confident in this mr, and it should be on master branch. Also you can publish this commit for other reviewers.
p.s. updated (you can cherry-pick, merge, publish via UI)
Do the following procedure:
1) Go to the draft change page
2) Click on Cherry Pick button
3) Write "master" in the Cherry Pick to Branch field
4) Adjust the Cherry Pick Commit Message if needed
5) Click on Cherry Pick Change button
It'll be created a NEW CHANGE cherry-picked from the draft change. Go to the new change page and follow the regular Gerrit process (review, approve, submit). The original draft change can be abandoned or deleted.
We use Jenkins to verify patch sets. Sometimes Jenkins needs do some changes on the patch set. So it commit --amend the changes and then uploads the new patch set.
It work nicely besides the fact, that all manual reviews made to the original patch set get erased.
How can I push a new patch set (from Jenkins) without loosing all existing reviews/votes?
Be aware that, in the situation you have described, you have a new patchset and, excluding in special situations, you don't want votes of the old patchset copied forward to the new patchset. For example: if someone have approved the patchset1 and Jenkins pushes the patchset2, probably he/she doesn't want to have his/her vote automatically copied to patchset2.
Said that: you can control how votes will/won't be copied forward to new patchset setting the label.LABEL-NAME.copyXXXXX options of the project. See more info in Gerrit documentation here.
I am Sajid, I like to know Is it possible that I can go back to my previous patch in my commit. I can explain:
I commit something. On the way to delivery, i fixed and update things and pushed into gerrit with commit --amend. But what I am experiencing now my last patch is a faulty so I like to go back to previous patch. and I don't know how can i point to my previous patch. And I also like to know will it be the same procedure even If I go to any previous patch.
thanks in advance.
As this answer said, patchsets can not be reverted. so first you have to checkout one of the previous patchset. you can get the command from Gerrit review board at each patchset download panel. For example:
git fetch https://android.googlesource.com/kernel/tegra refs/changes/43/69243/2 && git checkout FETCH_HEAD
After checking it out amend it to generate new commit hash then pushed again as a new patchset.
I have a library on github which uses rebar, but it has never been tagged via git. As of this writing, the app.src file indicates it is version 0.1 (this has never been changed).
I'd like to make some commits which will change some of the function definitions. I need to use tags and application versions so this doesn't negatively impact users, but I'm unclear on the order I'm supposed to tag, bump, etc.
What steps do I take now and in the future in order to ensure that users can code to the version of their choice?
I use the following scheme in my repositories:
X.Y.Z where X is major, Y is minor and Z is patch releases (taking some ideas from
Semantinc Versioning)
The order I change .app.src files and tags is as following:
Make the change, bump version number in the .app.src file and commit it with a
nice commit message.
Tag that commit using the same version number as in the .app.src file. I enter a
tag message of the following form:
Version X.Y.Z
- New Feature 1
- New Feature 1
- Fix this and that
The tag is then GPG signed with my signature (using the -s flag)
Push the commit with git push && git push --tags to upload both the commit and the tag to the server.
I don't use semantic versioning's "vX.Y.Z" scheme as tags because I think it's superflous and doesn't look very good.
Once you have proper tagging and versioning (of your choice) your users should be able to rely on using the Git tags as is.
You can see the results here: https://github.com/eproxus/meck (you need to download the code to see the tag messages and verify the GPG signature).