Hacker News new | ask | show | jobs
by kettro 1881 days ago
I’ve used Gerrit at 3 different places, now including at Google. It is, by far, the best git experience.

The patch workflow is smooth and just a great experience. It is vastly improved by some git aliases (which you can set up in your gitconfig), but is, in general, very smooth. It allows for local branches to a single upstream, topic tagging, and a reasonable learning curve. Much better than GH.

It would be very well served to have a web-based offering (like GitHub/Lab).

1 comments

> The patch workflow is smooth a

Can you explain what a "patch workflow" is and in what sense Github is not a "patch workflow"?

There's some confusion since some people associate "patch workflow" with an email-based workflow.

A patch/diff workflow operates at the level of individual diffs, rather than a branch identified by base and head refs like with pull requests.

Email is one (very clunky) way of implementing such a workflow, there's other tools like Gerrit, Reviewable or Phabricator that are more friendly.

Thanks. Can you explain why that might be a good thing?

If I update the diff, does it become a new reviewable item, independent from the first version?

I've never worked at a large tech company but my understanding is that at e.g. google there is some sort of monorepo, so it would presumably zoom forwards while a commit is under review. Even so, why is it not a good thing to review the commit in an explicit location in the historical commit graph?

Patches would still have a base, it's really more about about the data model. It's possible to synthesize a GitHub PR from a Gerrit CL and vice-versa.

In fact, Gerrit is entirely based on Git and you can simply clone any given CL.