From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id BD1A01381F3 for ; Tue, 14 May 2013 14:40:32 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 55DACE095E; Tue, 14 May 2013 14:40:29 +0000 (UTC) Received: from mail-ve0-f175.google.com (mail-ve0-f175.google.com [209.85.128.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 697E0E0935 for ; Tue, 14 May 2013 14:40:28 +0000 (UTC) Received: by mail-ve0-f175.google.com with SMTP id cz11so685347veb.20 for ; Tue, 14 May 2013 07:40:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=+OoZiTrK+g25Txj0FdVcmHDMHxaRtm9uVe9kkZ1OecY=; b=qmuVwboqJp8hJnMeHjJUpjsSRadEMfyrLHueRQTxBTtCOMepy0NWeZfdpHHDTJU6LQ NR9YWCHzk7HuWoMj2vhyx7r1KpiE/HA0JzJpFe8m+e+T0zXb4Xac+0C9gP/CSWNJgUPx i8WyNtuKqWhIGiTeiDDgG54StlnwazyxLtmsFKIeyxtM1lPrAfhrSyZs03ijfIk7NhMc Ap1LKRMoPDwlKxuuuew5GZWOltb9u3f9KXcnCGMfUg5o3XQThicpdt8fSWOMMYcjXS7j TQgj8RE7lzpCweXe1Znst0QQWMZ5iLMUq0ilLtdxN6Xk4hxpAtKxWLXIm5NoqOOsfsIj RVlg== Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 X-Received: by 10.52.19.198 with SMTP id h6mr10430763vde.101.1368542427590; Tue, 14 May 2013 07:40:27 -0700 (PDT) Sender: freemanrich@gmail.com Received: by 10.52.183.74 with HTTP; Tue, 14 May 2013 07:40:27 -0700 (PDT) In-Reply-To: <20130514141905.13711.qmail@stuge.se> References: <20879.47550.568189.770408@a1i15.kph.uni-mainz.de> <20130512172003.9979.qmail@stuge.se> <39106330.P4KaKQNKU3@sammi> <20130514141905.13711.qmail@stuge.se> Date: Tue, 14 May 2013 10:40:27 -0400 X-Google-Sender-Auth: PaPjMjM4sZIH33qxFSR79LZJyw8 Message-ID: Subject: Re: [gentoo-dev] GitLab Feature-Set / Was: devmanual moved to github From: Rich Freeman To: gentoo-dev Content-Type: text/plain; charset=ISO-8859-1 X-Archives-Salt: 0713e22c-658f-4940-b74b-90003afc958c X-Archives-Hash: bd1c539c417e7b6ef50c734ae1bd7c54 On Tue, May 14, 2013 at 10:19 AM, Peter Stuge 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