Introducing the git-gerrit-subcommand

[Jun Sheng]

Hi, 

I've created this git-gerrit tool to ease the usage of Gerrit. 

Essentially, with this tool, developers can keep the edit-commit cycle while use an upload command to push the change for review. 

The renewed workflow looks like this:

- git gerrit workspace-start a-new-feature

- edit-commit cycle

- git gerrit upload

- repeat last two steps until the change is accepted (or abandoned) 

With the 0.0.1 version of this git-gerrit tool, the features are 

- [DONE] Workspace create/delete/sync
- [DONE] Upload Change
- [DONE] Rebase workspace to HEAD or newest patchset of related-change
- [TODO] Sparse checkout when creating workspace
- [TODO] Integrate with VSCode
- [TODO] A fuse filesystem to do lazy checkouts to save time

Comments and suggestions are welcome!

[Oswald Buddenhagen]

On Tue, Oct 31, 2023 at 09:34:18PM -0700, Jun Sheng wrote:
>I've created this git-gerrit tool [...] to ease the usage of Gerrit.
>
welcome to the club! :-D
https://wiki.qt.io/Git-gpush-scripts

there are also 'repo' (originally google/android) and 'git-review'
(openstack), just to name the better known ones.

regards

[Jun Sheng]

Thanks Oswald,

To me and a few users around me, the most intuitive thing about gerrit is `git commit -a` in the development cycle. 

As I realized that a change in gerrit is just a squashed branch, I decided to create this tool to make a different(maybe easier) user experience. 

We make Cloud easier!

Jun Sheng | Solutions architect, Google Cloud

--
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to a topic in the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/repo-discuss/xuunyFzM-2s/unsubscribe.
To unsubscribe from this group and all its topics, send an email to repo-discuss...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/repo-discuss/ZUNclB6n13Qkge7u%40ugly.

[Jun Sheng]

s/intuitive/diffcult/

[Sven Selberg]

On Thursday, November 2, 2023 at 1:04:04 PM UTC+1 Jun Sheng wrote:

Thanks Oswald,

To me and a few users around me, the most intuitive thing about gerrit is `git commit -a` in the development cycle. 

Just for clarity, `git commit --amend` is a git command unrelated to Gerrit that is useful when you want to create a new version of a commit and not a new commit on top of the current HEAD.

 

As I realized that a change in gerrit is just a squashed branch, I decided to create this tool to make a different(maybe easier) user experience. 

You can squash a branch into a commit but which is what change is (together with a bunch of meta data such as review comments and a history of previous versions, patchsets), but a change is not a squashed branch, they are two different things.

Other git-based SCM systems doesn't have the ability to keep a history of previous commit-versions and have therefor opted to stack changes to the initial commit of a review on top of eachother:
123d... Fix speling

123c... Rename var

123b... Refrase doc-string

123a... Actual feature

And in this case the top 3 commits have no value in the target branch but only make it more difficult to review, roll-back features, track changes in the code base ...

It is generally a better idea to learn about `git commit --amend` and how to handle stacks of commit instead of trying to hide the complexity behind a tool.

Ex:

You can have separate commits in a stack that actually should be separate commits:

456e... UI for Feature X

456d... API for Feature X

456c... Logic for Feature X

456b... Storage for Feature X

456a... Refactor in preparation of Feature X

In this case you don't want to squash and create just one commit/change/review for the whole stack but keep the commits/reviews/changes as separate commit, if for nothing else to make it immensely easier to review.

And to accomplish this you'll need to learn about how git stacks,  `git commit --amend` and `git rebase -i ` works. But once you do your, and your colleagues life, will become so much easier and productive.

- Sven

[Jun Sheng]

Hi Sven, You are absolutely right about the positive parts of a "change" in gerrit. 

However, I want to point out that in fact, `git commit --amend` (sorry I mis-spelled the command in my previous emails) does not really amend a commit, it creates a new commit and "amends" the pointer(HEAD) pointing to the old commit to point to the newly created commit.

** Reality

When asked, 9 out of 10 engineers in my team prefer to use Github than Gerrit because the `git commit --amend` is so non-trivial and anti-pattern.  

Also analytical data (1, 2) shows that there are averagely 3 to 4 commits per pull request throughout the Github, this implies save/commit actions are 3 times of send-to-review actions. Such reality drives me to think about letting users keep on using traditional `git commit` and add an additional command for the action send-to-review in Gerrit. 

** Compare `amend` and `branch-then-squash`

Consider a process of sequentially making 3 edits and using `git commit --amend` 3 times, this process will generate 3 commits:

Assume the base commit is B, commit message is M, and T1..T5 is the tree as a result of each edit. 

               (I)

                           HEAD

                            |

C1(M, T1, B)  C2(M, T2, B)  C3(M, T3, B)

/             /             / 

+-------------+-------------+

|

B

Compare to the branch approach, we use normal `git commit`:

                (II)

                                HEAD

                                 |

C1(M, T1, B) -- C2(M, T2, C1) -- C3(M, T3, C2)

/

B

We can see at the end of both processes, the Tree objects are identical. Hence if we squash the branch in the second process at the last step, we have a commit C3'(M, T3, B):

squash(C1..C3, B) => C3'(M, T3, B)

it can be seen that this C3' is actually identical to C3 in the first process. It can also be seen that in process I the history C1 and C2 are discarded. 

** The tool

My tool, in compare to many other approaches(repo, gpush, review), the essential difference is my tool letting users do `git commit` in their daily development cycles while adding two commands for "start a new feature" and "send to review" as these two actions are far lesser frequent. 

Gerrit is a great tool, I want to make it easier to use. 

To view this discussion on the web visit https://groups.google.com/d/msgid/repo-discuss/ae38a2c1-8cbf-469b-b668-1e00a34f6669n%40googlegroups.com.

[Sven Selberg]

On Monday, November 6, 2023 at 12:26:40 AM UTC+1 Jun Sheng wrote:

Hi Sven, You are absolutely right about the positive parts of a "change" in gerrit. 

However, I want to point out that in fact, `git commit --amend` (sorry I mis-spelled the command in my previous emails) does not really amend a commit, it creates a new commit and "amends" the pointer(HEAD) pointing to the old commit to point to the newly created commit.

Absolutely, amending a commit necessarily means creating a new commit due to the immutable nature of a commit.

 

** Reality

When asked, 9 out of 10 engineers in my team prefer to use Github than Gerrit because the `git commit --amend` is so non-trivial and anti-pattern.

git is non-trivial since it is attempting to solve non-trivial problems, I'd phrase it like "9 out of 10 engineers in your team haven't taken the time to gain a deeper understanding of git in general and git commit --amend in particular".
I'm also curious as to what makes you label  "git commit --amend" is an anti-pattern? Specially when accepting "squash" as a viable alternative. (I don't consider "squash" an anti-pattern but it is certainly less non-trivial than "commit --amend" is)

 

Also analytical data (1, 2) shows that there are averagely 3 to 4 commits per pull request throughout the Github, this implies save/commit actions are 3 times of send-to-review actions. Such reality drives me to think about letting users keep on using traditional `git commit` and add an additional command for the action send-to-review in Gerrit. 

** Compare `amend` and `branch-then-squash`

Consider a process of sequentially making 3 edits and using `git commit --amend` 3 times, this process will generate 3 commits:

Assume the base commit is B, commit message is M, and T1..T5 is the tree as a result of each edit. 

               (I)

                           HEAD

                            |

C1(M, T1, B)  C2(M, T2, B)  C3(M, T3, B)

/             /             / 

+-------------+-------------+

|

B

Compare to the branch approach, we use normal `git commit`:

                (II)

                                HEAD

                                 |

C1(M, T1, B) -- C2(M, T2, C1) -- C3(M, T3, C2)

/

B

We can see at the end of both processes, the Tree objects are identical. Hence if we squash the branch in the second process at the last step, we have a commit C3'(M, T3, B):

squash(C1..C3, B) => C3'(M, T3, B)

it can be seen that this C3' is actually identical to C3 in the first process. It can also be seen that in process I the history C1 and C2 are discarded. 

The dragon that is hidden here is that:

* In case 1 the developer actively creates C1 C2 and C3 and is therefore aware of C3 and it's connection to C1 and C2 and therefore has the ability to fix issues that arises since "what you see is what you get".

* In case 2 the developer's reality consists of C1, C2, C3 whereas the developer is blissfully unaware of C3' (I assume, since "squash" is more complex than "commit --amend" but I am also speaking from experience).

   When an issue arises with the C3' commit in Gerrit the developer has no insight in what causes it (due to the "black box" that creates C3' from C1,C2,C3

 

** The tool

My tool, in compare to many other approaches(repo, gpush, review), the essential difference is my tool letting users do `git commit` in their daily development cycles while adding two commands for "start a new feature" and "send to review" as these two actions are far lesser frequent. 

Speaking as a former Gerrit admin of a Gerrit instance where one such tool was in place it was the source of much confusion, frustration and even larger support burden for the Gerrit team due to the disconnect between what they saw locally and what turned up in Gerrit.

Once we came around to removing that (what we considered) "legacy" functionality it was discovered that a majority of users had chosen to not use the tool but instead use a vanilla Gerrit workflow (with the aforementioned "git commit --amend" and "git rebase --interactive") since they experienced that the cost of using the squash-branches-and-upload-to-Gerrit tool was too high due to the complexity and lack of insight and control. I.e. the Gerrit team was spending a large chunk of their bandwidth supporting a small click of people that didn't want to learn something new.

Finally, in my mind has far better ROI to gain a deeper understanding of git compared to learning a new tool. But that's just my opinion.