From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2.migadu.com ([2001:41d0:403:4876::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms1.migadu.com with LMTPS id 0MWwDhyCZWYLAwAAe85BDQ:P1 (envelope-from ) for ; Sun, 09 Jun 2024 12:21:16 +0200 Received: from aspmx1.migadu.com ([2001:41d0:403:4876::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2.migadu.com with LMTPS id 0MWwDhyCZWYLAwAAe85BDQ (envelope-from ) for ; Sun, 09 Jun 2024 12:21:16 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=none; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org"; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1717928475; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post; bh=rFucqv3YRZlKegK3iWtmjjWITqnASo8e+7A/G/RNGZA=; b=dPZFh3mD1t6cZ3F3AyAK7jaoqZ/glRhHndLXXDgc9BtmCO9Jn5p/Vn80W6ONNatz/j3/I8 DJz7bK4EI58j7iB75XVkCVlqTxGx6eidIRzXjt9aqPGDZFQ5TRY5rsQjWfQwkRDaJUcbik PlUXT9zj5by4Kwe8vURcckQXgPOxp4Wofgj42VggQEkKXuoHddNNW1YNT6rY8MBZm9JfP4 xoiUdF97ofLwfsb7eWYsJWh8mhbf9OaZxdDQ5QYzAvtLlPTKJcCe5JFhobHc7CZGxH6aOJ 9A8S3cFki721639dPce2x8IxZK6eXM1JBTvrZ4uIhufgt0/oPt2sZZQSJPDxoQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org"; dmarc=none ARC-Seal: i=1; s=key1; d=yhetil.org; t=1717928475; a=rsa-sha256; cv=none; b=p5WQFQdxI6E7xc7lFcH7xnQ270FfXZBOTj5wSZy0MzSfDbr5F43trIIeb/PEjt7t+CTaV4 4rAGLtIenMiATCaRTxJs8x0r87sM/0jQjq0vMl4K1EQM1Xl62i9CRd+TTfnYylQX63GHZG qJTfWUeFPzZQLCwmD8VS09JUbCefjLurn39i4WwZb6jZx1VMRfbbE5/HLwFYpRXnwEzs8G X9HeM6l/U6aPL6wyffeob2R/u0Rr2AoteLb9K24OSMqySU8rAVaJEiZJ8RYVELoiGGSLtk oIe5tTVXiD7Kqx2MBitDGMWBXPkKvD6tDOgOKgsBltP4La3VOhNx/AhV2SteNw== Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id D3DE17EB37 for ; Sun, 9 Jun 2024 12:21:15 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sGFfY-0002GZ-P6; Sun, 09 Jun 2024 06:21:00 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sGFfX-0002GI-20 for guix-devel@gnu.org; Sun, 09 Jun 2024 06:20:59 -0400 Received: from mira.cbaines.net ([212.71.252.8]) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sGFfV-0005tu-3D for guix-devel@gnu.org; Sun, 09 Jun 2024 06:20:58 -0400 Received: from localhost (unknown [212.132.255.10]) by mira.cbaines.net (Postfix) with ESMTPSA id E19D427BBE2; Sun, 9 Jun 2024 11:20:55 +0100 (BST) Received: from felis (localhost.lan [127.0.0.1]) by localhost (OpenSMTPD) with ESMTP id 92ec7930; Sun, 9 Jun 2024 10:20:55 +0000 (UTC) From: Christopher Baines To: guix-devel@gnu.org, efraim@flashner.co.il Cc: 70456@debbugs.gnu.org Subject: Re: branch core-updates updated (c8c6883398 -> 0e06c9697a) In-Reply-To: (Efraim Flashner's message of "Sun, 9 Jun 2024 12:54:27 +0300") References: <171792086189.17847.16499633131068637226@vcs2.savannah.gnu.org> <87jziy1mal.fsf@cbaines.net> User-Agent: mu4e 1.12.4; emacs 29.3 Date: Sun, 09 Jun 2024 11:20:53 +0100 Message-ID: <87frtm1koq.fsf@cbaines.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Received-SPF: pass client-ip=212.71.252.8; envelope-from=mail@cbaines.net; helo=mira.cbaines.net X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: guix-devel-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN X-Spam-Score: -7.94 X-Migadu-Queue-Id: D3DE17EB37 X-Migadu-Scanner: mx10.migadu.com X-Migadu-Spam-Score: -7.94 X-TUID: q94sNxAcai+p --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Efraim Flashner writes: > On Sun, Jun 09, 2024 at 10:46:10AM +0100, Christopher Baines wrote: >> guix-commits@gnu.org writes: >>=20 >> > efraim pushed a change to branch core-updates >> > in repository guix. >> > >> > from c8c6883398 gnu: dico: Add libxcrypt dependency. >> > new 9804f8c149 gnu: coeurl: Update to 0.3.1. >> > new 51c7b6d76f gnu: font-gnu-freefont: Build with newer fontforge. >> > new 0e06c9697a gnu: Remove fontforge-20190801. >> > >> > The 3 revisions listed above as "new" are entirely new to this >> > repository and will be described in separate emails. The revisions >> > listed as "add" were already present in the repository and have only >> > been added to this reference. >>=20 >> These changes confused me as I was looking at the trying to work out why >> they needed to be pushed to core-updates. Eventually I figured out that >> Git is right, these commits are entirely new, but they duplicate >> existing commits already pushed to master (e.g. 0e06c9697a is a >> duplicate of 3d5f4b2d7dda). >>=20 >> I know the new guidance says to "Avoid merging master in to the branch", >> but one of the reasons for that is to avoid situations just like this >> where merges are done incorrectly and commits are duplicated between >> branches. >>=20 >> To fix this, I think we should rebase core-updates on master and drop >> these commits. > > I wasn't aware I was "doing it wrong" with this, I saw that coeurl 0.3.0 > failed on core-updates but a bump to 0.3.1 fixed the build, and it could > go to master also. Similar story with working to remove > fontforge-20190801 which no longer built on core-updates. I figured that > applying the patch to both branches would make it easier to merge master > into core-updates since there would be less drift between the two. You're right regarding drift, but unfortunately I think this duplication of commits creates merge conflicts, or at least makes them much more likely. > What is the correct way to apply a patch to multiple branches? I'd frame the problem differently, we don't want multiple branches, we want everything on master. Unfortunately for some changes that is hard to test and creates too much churn, so for those changes they go to a branch where they can be built and tested prior to pushing/merging them to master. To avoid changes happening on a topic branch and master, I think it's important that any change that can be made on master, is made on master. That should avoid the problem where someone else comes along and doesn't realise a change has been made on core-updates, and duplicates that on master. In this instance, you pushed the changes to master, which is great. I realise it does require more up front effort, but if you see a failing build on a topic branch that's fixed by some change on master, the topic branch should be rebased to include those changes. Providing it's done correctly, merging should be fine as well, but the docs now say to avoid that and prefer rebasing (mostly because of how merging has introduced duplicate commits in to core-updates) This rebasing or merging will minimise the drift between the two branches as well, while avoiding Git conflicts and commit duplication. So I don't think we want to be applying patches to multiple branches. If it can be applied to master, it should be applied there, then all the branches should be rebased to include it. Does that make sense? This isn't really a "doing it wrong" thing, more that we need to try and optimise the process for managing branches. I haven't got a concise definition of what we're trying to optimise for, but in this instance we want to avoid Git issues like merge conflicts and avoid duplication and complexity by making changes that can be made on master, just on master. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKlBAEBCgCPFiEEPonu50WOcg2XVOCyXiijOwuE9XcFAmZlggVfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNF ODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcRHG1haWxAY2Jh aW5lcy5uZXQACgkQXiijOwuE9XfRJQ/7B6KRFV4aTJhTsvzsx3XFBp2aMS1VWIOX hVOuEC89bMqixerzfBe7dPqyt/8SYPetD3dV2EHR5MqPrpQO1r0e5T9yJlab3ehc Wy+JIQySy3KbtiSH4dDILyld/sJ7TVbC/YS/zBFPghFT+/egV0DzOvasvFUNKLzS ggzMDJxT5SssgQMAV2SnNOV9FDEkw4Ubmk0nqeladGTzAm4n1ajMomMNAlw8dV9y /TOnwevnuIKY6lx0aY52Y6qpiLGh510Nc8xaPQqXkBtulGq1Tes8s4nmft7zkNg3 vKRYThfPJ2ymMXtPZmpmNqB/Iy0pdO/g1TX6e5lYq+eXqoq9qLFPURAKrAt1w9B8 2ri8dpRO7WinKVr/g9k6XNf4r2HaUCtqxYpTxrUQnyFR0VJL+tli22CAJ39eLNfJ gKS3dCnhJyfCSAL43wWdcShIzNjIiHLfPOEvQor7P6lkYi7n5/8EUaPGm8yH2wWY bSvRefUanIx9Edv8mjVgMMmfUnyQ/9iRiapOkKxmf80y39aNlJSWk2MOTvdwP3v3 5P8Q7IdVg+Wt/xerUdnPrLcZfUuQn0sPSvZRW4zRIGF7xA6ufn4spj0ptnyCqLZN utYJUQIre3WKMJPsicYY6DSFOl0QxmQFttX52/H2quG/9/b2LfR0J+dsgVX7pfoO R53lYSeUIQ4= =vWmK -----END PGP SIGNATURE----- --=-=-=--