5 ms·
4 CRs stacked on eachother in Gerrit. It's that one killer feature of Gerrit that you cannot live without in other systems once you realize how powerful it is.
by q3k 6y ago
4 CRs stacked on eachother in Gerrit. It's that one killer feature of Gerrit that you cannot live without in other systems once you realize how powerful it is. Phabricator's Differential also does this, but it's comparatively extremely janky.
You literally just push four stacked commits to refs/for/master, they end up as 4 separate Change Requests (equivalent to what others call Pull Requests, each with a separate review process), each one explicitly marked as being dependent on another, and showing a diff only against that particular other base CR as if it were merged onto the target branch already.
Practically this just means you push your current HEAD to refs/for/master, Gerrit will take care of automatically creating all CRs for you and print out their URLs. Done. Ready for review.
Then, to update any of them, just amend them locally (address code reviews, rebase stack on top of current master/main, ...), make sure they're still stacked on eachother in Git (as four commits), and push them all again to the same endpoint. Gerrit will automatically update all affected CRs. It will deduce the intended order and state of CRs based on the local Git history pushed, mapping all commits to existing CRs based on the Change-Id present in each commit (automatically generated by Gerrit's local git hook).
None of the hacks that other siblings comments mention are required. It just works.
- zamalek 6y agoI imagine Pijul could do this quite naturally, as it describes everything as causal chains/DAGs (as I understand it). E.g. You could publish this[1] patch alongside all of its dependencies, and the UI could gate it behind it's dependencies. [1]: https://nest.pijul.com/pijul/pijul/changes/VO5OQW4W2656DIYYRNZ3PO7TQ4JOKQ3GVWE5ALUTYVMX3WMXJOYQC https://nest.pijul.com/pijul/pijul/changes/VO5OQW4W2656DIYYR...
- pmeunier 6y agoIn the entire history of Pijul, you probably picked the best example of how to get your reviewer stop being in love with you. That change fixed several hundred errors caused by the removal of a dependency.
- zamalek 6y agoThat's hilarious, I have been reading about Pijul for a few days so I don't have any real experience with it yet.
- pmeunier 6y agoIf you want a better example, see how I manage two different version of my SSH library for Rust, Thrussh: https://nest.pijul.com/pijul/thrussh https://nest.pijul.com/pijul/thrussh The problem this is solving is that the Rust ecosystem is in the middle of transitioning between two version of its async base library, Tokio: most libraries have transitioned, but the most used HTTP library (Hyper) hasn't. This forces any user that wants both HTTP and another network protocol (SSH, for instance) to stay on the older version. However, we can't all keep waiting on Hyper. Pijul's solution is to push the same bugfixes to two different channels, one of which includes an extra patch for transitioning to Tokio-0.3 (the newer version). Since the identity of patches is preserved, no rebase is needed, and conflicts solved once are solved forever (no rerere).
- nsm 6y agoSeconded. This notion of "stacked diffs" is extremely powerful and I miss review systems that lack it. Currently using it for years now in Phabricator by following https://medium.com/@kurtisnusbaum/stacked-diffs-keeping-phabricator-diffs-small-d9964f4dcfa6 https://medium.com/@kurtisnusbaum/stacked-diffs-keeping-phab...