From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 38780139694 for ; Thu, 27 Jul 2017 22:38:19 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id BB0CB1FC0BF; Thu, 27 Jul 2017 22:38:13 +0000 (UTC) Received: from blaine.gmane.org (unknown [195.159.176.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 6C3361FC08D for ; Thu, 27 Jul 2017 22:38:13 +0000 (UTC) Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1darPx-0003wy-EM for gentoo-dev@lists.gentoo.org; Fri, 28 Jul 2017 00:38:05 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-dev] Re: [RFC pre-GLEP] Gentoo Git Workflow Date: Thu, 27 Jul 2017 22:37:58 +0000 (UTC) Message-ID: References: <1500969906.1206.1.camel@gentoo.org> 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 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@blaine.gmane.org User-Agent: Pan/0.143 (Quaint little villages here and there; b4329315c) X-Archives-Salt: a63ce14f-1508-47c3-bd4f-7212a8a651d5 X-Archives-Hash: 3ed43bd2c0bd2d35c04b4f0bcf556071 Michał Górny posted on Tue, 25 Jul 2017 10:05:06 +0200 as excerpted: > ==Specification== > ===Branching model=== > The main branch of the Gentoo repository is the master > branch. All Gentoo developers push their work straight to the master > branch, provided that the commits meet the minimal quality standards. > The master branch is also used straight for continous user repository > deployment. s/continous/continuous/ > Since multiple developers work on master concurrently, they may be > required to rebase multiple times before being able to push. Developers > are requested not to use workflows that could prevent others from > pushing, e.g. pushing single commits frequently instead of staging them > and using a single push. This is unclear as to which of the two behaviors is encouraged vs. discouraged. Maybe just add an an explicit "(encouraged)" and "(discouraged)" by each as appropriate? > Developers can use additional branches to facilitate review and testing > of long-term projects of larger scale. However, since git fetches all > branches by default, they should be used scarcely. For smaller projects, > local branches or repository forks are preferred. Nit-picking/quibble: "Can" vs. "may": While "can" is perfectly appropriate as used here in informal settings, "may" is more formal (with "can" reserved for whether it's technically possible, not at issue here or it wouldn't need mentioned, while "may" indicates it's approved/recommended, there's a child's game, "Mother may I", that I recall reinforcing this when I was young). Since this is intended as a GLEP it's arguably quite formal and "may" /may/ be more appropriate, thus my mention of the issue altho either should be well understood and "can" would be entirely appropriate if the context isn't considered quite that formal. Entirely a judgment call. > Unless stated otherwise, the rules set by this specification apply to > the master branch only. The development branches can use relaxed rules. Can/may... There may be other uses I won't mention but if you decide it's worth changing at all, a search and evaluate usage may be worth it. > Rewriting history (i.e. force pushes) of the master branch is forbidden. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman