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 |