# My workflow with git-cl + Rietveld

DevFeed: [My workflow with git-cl + Rietveld](<https://devfeed.tech/articles/my-workflow-with-git-cl-rietveld-21554.md>)

Original publisher: [Read original article](<http://lackingrhoticity.blogspot.com/2010/08/my-workflow-with-git-cl-rietveld.html>)

Author: Mark Seaborn (noreply@blogger.com)

Published: 2010-08-11T11:49:00Z

Content type: tutorial

Language: en

Sources: [Mark Seaborn](<https://devfeed.tech/sources/mark-seaborn.md>)

Topics: [Git](<https://devfeed.tech/topics/git.md>), [Code review](<https://devfeed.tech/topics/code-review.md>), [Development](<https://devfeed.tech/topics/development.md>)

Tags: [code-review](<https://devfeed.tech/tags/code-review.md>), [git](<https://devfeed.tech/tags/git.md>), [latency](<https://devfeed.tech/tags/latency.md>), [workflow](<https://devfeed.tech/tags/workflow.md>)

## AI overview

The article describes a Git workflow for managing dependent changes submitted separately for review through Rietveld. It uses one branch per change, rebases later changes onto revised earlier ones, and squashes commits before uploading or committing upstream. The author also explains problems caused by git-cl's limited support for dependent patch series, including manual tracking, conflicts, and lost history.

## Source excerpt

Git's model of changes (which is shared by Mercurial, Bazaar and Monotone) makes it awkward to revise earlier patches. This can make things difficult when you are sending out multiple, dependent changes for code review. Suppose I create changes A and B. B depends functionally on A, i.e. tests will not pass for B without A also being applied. There might or might not be a textual dependency (B might or might not modify lines of code modified by A). Because code review is slow (high latency), I need to be able to send out changes A and B for review and still be able to continue working on further changes. But I also need to be able to revisit A to make changes to it based on review feedback, and then make sure B works with the revised A. What I do is create separate branches for A and B, where B branches off of A. To revise change A, I "git checkout" its branch and add further commits. Later I can update B by checking it out and rebasing it onto the current tip of A. Uploading A or B to the review system or committing A or B upstream (to SVN) involves squashing their branch's commits into one commit. (This squashing means the branches contain micro-history that reviewers don't see and which is not kept after changes are pushed upstream.) The review system in question is Rietveld, the code review web app used for Chromium and Native Client development. Rietveld does not have any special support for patch series -- it is only designed to handle one patch at a time, so it does not know about dependencies between changes. The tool for uploading changes from Git to Rietveld and later committing them to SVN is "git-cl" (part of depot_tools). git-cl is intended to be used with one branch per change-under-review. However, it does not have much support for handling changes which depend on each other. This workflow has a lot of problems: When using git-cl on its own, I have to manually keep track that B is to be rebased on to A. When uploading B to Rietveld, I must do "git cl u