Re: [gentoo-dev] GitLab Feature-Set / Was: devmanual moved to github

[Rich Freeman <rich0@gentoo.org>]

On Tue, May 14, 2013 at 10:19 AM, Peter Stuge <peter@stuge.se> wrote:
> 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.
>

Suppose master is Gentoo Portage.  I clone it, make a change to
package foo, and push that commit to gerrit.  You clone it, make a
change to package bar, and push that commit to gerrit.  Those two
commits go into two different requests and don't interfere (well, they
might when merged if they contain conflicts - no avoiding that).  If
at that point somebody else clones the repo they get the official repo
without either of our changes, until at some point our changes get
merged.

It is true that revisions of commits do update each other, but this is
generally desirable.  What is important is that each logical change
stays isolated.

The only way to do this with branching is to have a branch per change
(which could be merged and deleted of course).  Gitlab doesn't seem to
support this though - I don't think there is any safe way to allow
random public users to create branches, and of course if anybody does
this they are published to the world.  Gerrit keeps changes more
tucked away, so that everybody is working off the official repo.  If
you just have everybody share one public branch then it will be a
hodge-podge of commits that require a lot of cherry-picking to work
with.  The public branch itself might not even work, or it might need
constant cleanup.  It might even contain trojans so cloning it would
be at your own risk (it would be safer to clone master and push to
public, which means that everybody is stepping on each other's toes).

Branches do make sense if you have groups working together on a single
change.  I'd encourage them for this use.  However, in the case of
isolated patches the Gerrit model seems better.

Again, I could be missing some Gitlab feature.

>
> 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.
>

I know a lot of projects like Gerrit (Cyanogenmod comes to mind).
Sure, it is Java, but I'd think it could be reasonably well-contained
in a VM/etc.  It could even be hosted - as long as we have backups/etc
and can recover to our own infra I'd consider that pretty low-risk.

Rich