Gentoo Archives: gentoo-dev

From: Rich Freeman <rich0@g.o>
To: gentoo-dev <gentoo-dev@l.g.o>
Subject: Re: [gentoo-dev] GitLab Feature-Set / Was: devmanual moved to github
Date: Tue, 14 May 2013 14:40:32
Message-Id: CAGfcS_kMOjaK=1gNhyu-170D8bVjfxE2PbA+iBNvrikDuE6Jxg@mail.gmail.com
In Reply to: Re: [gentoo-dev] GitLab Feature-Set / Was: devmanual moved to github by Peter Stuge
1 On Tue, May 14, 2013 at 10:19 AM, Peter Stuge <peter@×××××.se> wrote:
2 > Rich Freeman wrote:
3 >> Gerrit also requires letting the public push, but those pushes go
4 >> to a contained area and each commit is isolated.
5 >
6 > Hm, how do you mean isolated?
7 >
8 > Gerrit introduces the convention to create a unique identifier for a
9 > change the first time a commit is created. If later iterations of
10 > that same logical change (e.g. a second commit after review) keep the
11 > Change-Id line from the original commit message then Gerrit knows
12 > that this commit is a new version of the old one as opposed to an all
13 > new change.
14 >
15
16 Suppose master is Gentoo Portage. I clone it, make a change to
17 package foo, and push that commit to gerrit. You clone it, make a
18 change to package bar, and push that commit to gerrit. Those two
19 commits go into two different requests and don't interfere (well, they
20 might when merged if they contain conflicts - no avoiding that). If
21 at that point somebody else clones the repo they get the official repo
22 without either of our changes, until at some point our changes get
23 merged.
24
25 It is true that revisions of commits do update each other, but this is
26 generally desirable. What is important is that each logical change
27 stays isolated.
28
29 The only way to do this with branching is to have a branch per change
30 (which could be merged and deleted of course). Gitlab doesn't seem to
31 support this though - I don't think there is any safe way to allow
32 random public users to create branches, and of course if anybody does
33 this they are published to the world. Gerrit keeps changes more
34 tucked away, so that everybody is working off the official repo. If
35 you just have everybody share one public branch then it will be a
36 hodge-podge of commits that require a lot of cherry-picking to work
37 with. The public branch itself might not even work, or it might need
38 constant cleanup. It might even contain trojans so cloning it would
39 be at your own risk (it would be safer to clone master and push to
40 public, which means that everybody is stepping on each other's toes).
41
42 Branches do make sense if you have groups working together on a single
43 change. I'd encourage them for this use. However, in the case of
44 isolated patches the Gerrit model seems better.
45
46 Again, I could be missing some Gitlab feature.
47
48 >
49 > While Gerrit is probably most often used as a web application, it's
50 > possible to perform most operations, including review, submit and
51 > reject, via SSH. The only thing missing from the SSH interface is
52 > doing inline review. The web interface allows writing review comments
53 > per line in the commit, this is unfortunately not possible via SSH.
54 >
55
56 I know a lot of projects like Gerrit (Cyanogenmod comes to mind).
57 Sure, it is Java, but I'd think it could be reasonably well-contained
58 in a VM/etc. It could even be hosted - as long as we have backups/etc
59 and can recover to our own infra I'd consider that pretty low-risk.
60
61 Rich