CODEWITHSUNDEEP
gitpushgerrit
Oren S
Oren S

Reputation: 1872

How can I push an unchanged patchset to gerrit and avoid creating a new version?

I am working in a small team using Git/Gerrit as source control/code review.
When developers in the team want to submit their work, they commit/push to gerrit and start working on a new feature.
In addition, developers are encouraged to push their work whenever they can and they usually work on top of already submitted changes (through cherry-picking of the relevant changes) which are currently under review.

Problem is, when developers try to push changes they also push the change's history. As a side-effect these changes get new versions with no difference from previous versions of the same change. Also, the developer now has to be given a 'forge' permission (assuming some of the cherry-picked changes weren't his)

Example: Suppose the history of one of Adam's branch looks like this (higher change is latest):

Change 3 (Author: Adam, currently in work)
change 2 (Ahthor: Charlie)
change 1 (Author: Bath)
Master

Now, changes 1,2 were cherry-picked from gerrit, and did not change.
When Adam pushes his patch, he must be able to forge committer on changes 1,2 and they get newer versions (without any difference from previous push)

Can someone please advise how to avoid this behavior? Are we doing something wrong?

Upvotes: 1

Views: 1704

Answers (2)

Brad
Brad

Reputation: 5532

Gerrit is creating new versions of these patchsets because there were changes - when the developers cherry-picked the changes that are up for review, that modifies the git commit. The commit now has a different parent and a different SHA1.

There are 2 ways to avoid this:

  1. Take the time to properly review/verify/merge changes that are still under review before doing much more work on top of them
  2. Rather than cherry-pick the changes down locally, use checkout. This will keep the existing patchset as-is, so any commits on top will upload fine without modifying the existing patchset. However, this will move your place on the repository to where the patchset was when it was created - you won't have any commits that have been merged since that patchset was uploaded.

At dayjob, we use a combination of these 2 approaches depending on the situation. Good luck!

Upvotes: 2

Stefan
Stefan

Reputation: 859

We had a similar problem at our company. Gerrit comes with a script which you should add to your local repository (it works under windows, mac and linux). It runs automatically when a commit is made to your local repository and generates a commit id (adds it at the end of the commit message).

If at later point the SHA1 of the commit changes (due to amend for example), Gerrit will see that it is the same commit and will not create a new entry point, it will just update the files if the commit is still under review.

To copy the script go to your repository and do the following:

scp -p -P 29418 [email protected]:hooks/commit-msg .git/hooks/

Upvotes: 1

Related Questions