Rich Freeman wrote:
> Gerrit also requires letting the public push, but those pushes go
> to a contained area and each commit is isolated.
Hm, how do you mean isolated?
Gerrit introduces the convention to create a unique identifier for a
change the first time a commit is created. If later iterations of
that same logical change (e.g. a second commit after review) keep the
Change-Id line from the original commit message then Gerrit knows
that this commit is a new version of the old one as opposed to an all
new change.
Pushing to Gerrit looks and feels like pushing to a git repository but
in fact the push goes into Gerrit's own database ("contained area")
where it can be reviewed, iterated by pushing again as described
above, submitted (output into the project's (readonly) git repo) or
rejected.
The real beauty of Gerrit is that anything can be accepted into it
without affecting the project's real git repo at all, and that only
an OpenID is required for pushing.
Verification (testing) can be made a requirement before a commit can
be submitted in Gerrit, meaning that some test suite needs to pass
before a commit can enter the git repo.
Some of this can be orchestrated with multiple repositories and lots
of hooks, but Gerrit packages it all up quite nicely.
While Gerrit is probably most often used as a web application, it's
possible to perform most operations, including review, submit and
reject, via SSH. The only thing missing from the SSH interface is
doing inline review. The web interface allows writing review comments
per line in the commit, this is unfortunately not possible via SSH.
//Peter
