2

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.