Gerrit: Working around the "single-change:single-commit" principle. Need Feedback

Question

I have been using Gerrit in my work environment and I find it really amazing and powerful because of its elegant use of git's branching features to create virtual branches for code reviews (the "refs/changes/*" branches).

However a common pain point in using Gerrit I have came across is its "single-change:single-commit" principle.

When a user commits a new change for code review, he/she can use "git commit -m "My Message"; git push origin HEAD:refs/for/master" without trouble. When it comes to updating that change, another patchset to the same change has to be created using "git commit --amend" command only. This leads to loss of commit history for the user (who wants to keep all commits for reference) and can lead to large chunks for code review.

---

With my idea I propose to address the first part of the problem: loss of commit history for the user. We can add patchset description to patchsets manually from the Web UI. However in my workplace I see this feature seldom used and strongly feel that it's the same case at other places too where gerrit is used (I can be wrong here).

When the first patchset is committed (git commit -m "My Message"), let the commit message be the description of the patchset (Patchset 1 description: "My Message"). This commit will also create a change-id for the change.

For further patchsets, instead of amending the previous commit, let the previous change-id be reused and by using "git commit" instead of "git commit --amend" (which leads to commit-msg screen), we can add new commit message (leaving the change-id as is). This new commit message can be used as the description for new patchset (Let the new commit message be "Issue fixed" with same change-id, then Patchset 2 description: "Issue fixed").

This way the commit history of user is preserved and the new commit messages become patchset descriptions. All these patchsets have the same change-id.

---

Now the question arises, when the user wants to keep the change-id and when he/she wants to generate new change-id for a new change commit? If the user wants to create new change-id, he/she can simply delete the change-id line telling the commit hook to generate new change-id and hence a new change.

---

This is just a suggestion to effectively use the patchset description feature as well as cause minimal change to gerrit workflow and most importantly, preserve user commit history.

I would highly appreciate any kind of feedback and all the ways this can go wrong.

Answer 1

When it comes to updating that change, another patchset to the same change has to be created using "git commit --amend" command only. This leads to loss of commit history for the user (who wants to keep all commits for reference)

Commit history is kept in gerrit server in previous patchsets. You may get commit id and check it locally, if not expired locally (90 days save by default); you may use "Download" button and "Checkout" option in it.

​> and can lead to large chunks for code review.

​In Gerrit web interface you may select diff of a particular change not to base, but to a selected previous patchset. Modern versions also differentiate two kinds of differences by color: between diffs of these patchsets, and between their bases - the feature absent in all analogs I know. Isn't it enough?

I'd say you are trying to solve a non-existing issue.

PS: I work with Gerrit since 2012. Well, I could guess my experience doesn't cover all cases, but >90% - definitely.

Answer 2

The point of gerrit is to be a gatekeeper in front of a "definitive" git repo. Every commit in the definitive repo will have a 1:1 correspondence with a gerrit change id. By design, that involves amending commits that don't pass review.

You can, locally, have whatever history you like, so long as what you push to gerrit is one commit per change id.

E.g. a branch with multiple commits, representing each patchset, and a branch where you squash that into one commit to push to gerrit.