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 BF0C1139694 for ; Tue, 25 Jul 2017 13:36:17 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 94E801FC044; Tue, 25 Jul 2017 13:36:12 +0000 (UTC) Received: from smtp.gentoo.org (dev.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (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 3BB04E0C7A for ; Tue, 25 Jul 2017 13:36:12 +0000 (UTC) Received: from pomiot (d202-252.icpnet.pl [109.173.202.252]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mgorny) by smtp.gentoo.org (Postfix) with ESMTPSA id 5F9763416E7; Tue, 25 Jul 2017 13:36:10 +0000 (UTC) Message-ID: <1500989766.795.7.camel@gentoo.org> Subject: Re: [gentoo-dev] Re: [RFC pre-GLEP] Gentoo Git Workflow From: =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?= To: gentoo-dev@lists.gentoo.org Date: Tue, 25 Jul 2017 15:36:06 +0200 In-Reply-To: <2caadc57-87da-67fd-6824-8fbeb3e1ddc9@gentoo.org> References: <1500969906.1206.1.camel@gentoo.org> <2caadc57-87da-67fd-6824-8fbeb3e1ddc9@gentoo.org> Organization: Gentoo Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-684z+w0AsAbb6pmtTC2n" X-Mailer: Evolution 3.22.6 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-Archives-Salt: 64079e91-da50-40b2-958c-3c1935c04cfc X-Archives-Hash: 699dc74783aa62ae83aacd054a332c9a --=-684z+w0AsAbb6pmtTC2n Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On wto, 2017-07-25 at 22:28 +1000, Michael Palimaka wrote: > On 07/25/2017 06:05 PM, Micha=C5=82 G=C3=B3rny wrote: > > Hi, everyone. > >=20 > > There have been multiple attempts at grasping this but none so far > > resulted in something official and indisputable. At the same time, we > > end having to point our users at semi-official guides which change > > in unpredictable ways. > >=20 > > Here's the current draft: > > https://wiki.gentoo.org/wiki/User:MGorny/GLEP:Git >=20 > This looks really nice, thanks for working on it. >=20 > > * When doing a minor change to a large number of packages, it is > > reasonable to do so in a single commit. However, when doing a major > > change (e.g. a version bump), it is better to split commits on package > > boundaries. >=20 > In some cases we do prefer to make major changes on a set of related > package all in one commit. For example, we always bump the 240+ KDE > Applications collection together because that's how it's released. It's merely a recommendation. I don't want to cover every single use case because that would be insane. I'm already worried I've covered too many cases for people to read it all. > > =3D=3D=3DCommit messages=3D=3D=3D > > A standard git commit message consists of three parts, in order: a > > summary line, an optional body and an optional set of tags. The parts > > are separated by a single empty line. > >=20 > > The summary line is included in the short logs (git log -- > > oneline, gitweb, GitHub, mail subject) and therefore should > > provide a short yet accurate description of the change. The summary lin= e > > starts with a logical unit name, followed by a colon, a space and a > > short description of the most important changes. If a bug is associated > > with a change, then it should be included in the summary line as > > #nnnnnn or likewise. The summary line must not exceed 69 > > characters, and must not be wrapped. >=20 > Does a bug # really need to always be in the summary line? It can eat > valuable characters and tags which are pretty popular are equally valid I= MO. Tags don't appear on 'git log --oneline' or cgit/gitweb shortlog. If you are groking through multiple bugs, it is more convenient if you can find the bug no straight away. > > ** Bug: https://bugs.gentoo.org/NNNNNN;; = =E2=80=94 to > > reference a bug, > > ** Closes: https://github.com/gentoo/gentoo/pull/NNNN > ki>; =E2=80=94 to automatically close a GitHub pull request, > > ** Fixes: https://bugs.gentoo.org/NNNNNN;; = =E2=80=94 > > to indicate a fixed bug, >=20 > grepping the git log shows that 'Gentoo-bug' is much more common than > plain 'Bug'. 'Fixes' is hardly used at all, and I think it's a bit > confusing to use this for bugs as well as commits. 'Fixes' is the original tag used by other projects. 'Bug' is shorter than 'Gentoo-bug' and avoids repeating the obvious. Much like we do not have 'Gentoo-signed-off-by', 'Gentoo-thanks-to' and so on, having 'Gentoo-bug' is equally silly. Furthermore, full URLs should be used with tags. If you are already using tags (i.e. long form), don't do it half-way and put useless digits there. Put URL that will be interpreted by practically all visual git tools written ever. > > a few branches on the repository, and did not maintain them. The Infra > > had to query the developers about the state of the branches and clean > > them up. >=20 > Should 'The Infra' be 'The Infra team' or just 'Infra'? Yes, thanks. >=20 > > Gentoo developers are still frequently using Gentoo-Bug tag, > > sometimes followed by Gentoo-Bug-URL. Using both > > simultaneously is meaningless (they are redundant), and using the forme= r > > has no advantages over using the classic #nnnnnn form in the > > summary or the body. >=20 > I agree that using both is redundant, but I don't agree with > discouraging or banning the use of 'Gentoo-bug'. If someone prefers to > use it so it sits nicely with the other tags why stop them? I'm not stopping anyone. This is merely a suggestion. Encouraging two different tags for the same thing would be confusing to users. --=20 Best regards, Micha=C5=82 G=C3=B3rny --=-684z+w0AsAbb6pmtTC2n Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQKmBAABCgCQFiEEbbsHzE8NrQbqCv5BsHoa6u+0Rk4FAll3SUZfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDZE QkIwN0NDNEYwREFEMDZFQTBBRkU0MUIwN0ExQUVBRUZCNDQ2NEUSHG1nb3JueUBn ZW50b28ub3JnAAoJELB6GurvtEZOhBcQAKDje8RKfOzrDuuLtu1N/DaBGeWc4HpF DCWvhKoRUAYOIss69lV8oh7Z4xwSPTjcGQBeCL69bijxjn0aKJlatUSkhjQvIjyW Xj8sLTBuFtE+YB2zZM2rt4tQuhkI809z4kZH4GXtqvX3OcZlz1mFbkY640ZFcg6N cKLpBXqDAY5l/eZihZDWYGh8nzxXpTX+vbRqgxFkWU0T5zTX5Y0FcEfYyyrVZE+2 SxZ5MtnBndXRHozMGAu9uxAK+jatELQTzYyjCXHEfj7yiFzjZcyT4Yh8OES8IjKA WaIh8TRh9EHmz25J6QMb41cadOMLyShGrcJiv7MgfsHARPZMF4vRgdB2HX0HS/xx PAk/9zTBnA1OEMBZqMi9ykfUbuWnz77GXvlERwsjv8mkoBByfdelKtuIKymR1OJ0 CKqZQLIu/AcpXuQuYMSNCuRMwn8lotg7il57jbpY636NotS/6AJMnpOYrhs14vr2 hOKaFEMmu97w1YQkOqzwtnWiKr91SEKVZAG0XRKFVx7hnVC/+xV1i0svFSC7o6hV W4vSFqENtFt/nDOVEWDOmDLOeKxcu0Z64akSF06AdvDNcroMLZK6HrAIsXITL6U0 T1K31goH1NAcpUH+3wtcAvpOgoWbuNfNCNnls2m3RTeKwv7tY1llaT+TnM2sWJH3 fuvrZqp39fdn =U+5P -----END PGP SIGNATURE----- --=-684z+w0AsAbb6pmtTC2n--