From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id 2Ai7LAzfkWTPgAAASxT56A (envelope-from ) for ; Tue, 20 Jun 2023 19:17:00 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id yOtlLAzfkWTgqQAAauVa8A (envelope-from ) for ; Tue, 20 Jun 2023 19:17:00 +0200 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 716B6164B3 for ; Tue, 20 Jun 2023 19:17:00 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qBexP-0001Nb-Br; Tue, 20 Jun 2023 13:15:55 -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 1qBexA-0001Kz-8V for guix-devel@gnu.org; Tue, 20 Jun 2023 13:15:41 -0400 Received: from ns13.heimat.it ([46.4.214.66]) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qBex8-0003xj-CU for guix-devel@gnu.org; Tue, 20 Jun 2023 13:15:39 -0400 Received: from localhost (ip6-localhost [127.0.0.1]) by ns13.heimat.it (Postfix) with ESMTP id 694CF3008B3; Tue, 20 Jun 2023 17:15:35 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at ns13.heimat.it Received: from ns13.heimat.it ([127.0.0.1]) by localhost (ns13.heimat.it [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Dl8KEm4rld2; Tue, 20 Jun 2023 17:15:33 +0000 (UTC) Received: from bourrache.mug.xelera.it (unknown [93.56.171.217]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by ns13.heimat.it (Postfix) with ESMTPSA id 8CA1930087D; Tue, 20 Jun 2023 17:15:33 +0000 (UTC) Received: from roquette.mug.biscuolo.net (roquette [10.38.2.14]) by bourrache.mug.xelera.it (Postfix) with SMTP id 13F932723548; Tue, 20 Jun 2023 19:15:33 +0200 (CEST) Received: (nullmailer pid 4413 invoked by uid 1000); Tue, 20 Jun 2023 17:15:32 -0000 From: Giovanni Biscuolo To: Maxim Cournoyer Cc: Leo Famulari , Felix Lechner , Andreas Enge , Christopher Baines , guix-devel@gnu.org Subject: Re: Rebasing or merging? [was: Re: 01/03: gnu: wxwidgets: Add libxtst to inputs.] In-Reply-To: <87cz1yx1z2.fsf@gmail.com> Organization: Xelera.eu References: <168610879676.2825.9044237296073582277@vcs2.savannah.gnu.org> <20230607033317.826FCC23EDC@vcs2.savannah.gnu.org> <87sfb31qqp.fsf@cbaines.net> <87wn0aadrb.fsf@gmail.com> <87352xady4.fsf@gmail.com> <87y1kp8q11.fsf@gmail.com> <87cz1yx1z2.fsf@gmail.com> Date: Tue, 20 Jun 2023 19:15:32 +0200 Message-ID: <87352m12dn.fsf@xelera.eu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Received-SPF: pass client-ip=46.4.214.66; envelope-from=g@xelera.eu; helo=ns13.heimat.it 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_NONE=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 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1687281420; 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=O6g98A0fDpAMw9M7cRing+rpAogbbeY9E35GwtQYYj8=; b=DlMFA4uZCnBDgJsSe9MytgNt5H2qcJg+PTeY5LdcSP0NeeKm2RqOg0Ivwyy5op51oqu3dp OwzO0k3xjwCwimxGClZ8tq5ouKTdlnWCxjA4d0OrtX0pyymL5soCBkMCxb+YVPbYVBpFgC 3SuWiZevkDdjtxNeN7W06CbSrwdfVy0fW+bepzKMuydEhxSG8ywWDzIOwHeVlPmbxi6xGs CqKA11NbT5WNM8hKUR/BSld0J80BKEow75Ntm43Zx4AbGWtMU2k76quEcUi/h9c15/nyux v1lahkKOXkrkYPt8T+kLFVG9lwpLcrMh7b/bu6WWiYhBJLHCtgDJx2EfC9J+7A== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=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" ARC-Seal: i=1; s=key1; d=yhetil.org; t=1687281420; a=rsa-sha256; cv=none; b=ZL40FGG16U+h/YkrW/mDUcjvhNYj7iLabO2kGuzulf6lA/oZKIQLIyqBSeXVlEfLk5u9Wu Ea12Ny1UoyZGbinz6uKMukNE2lxN1PvoEEyg7oAWH5EjT3AyYPu0uYaNS/YNGl/dg7LeAA hESdUd1s/6v0wFXyPIomoGUqnGeS8dZEHZfZ9sWzKE7G7hlSfhthcN225YXddBZmtOouGs 5fepVbV3bP/q79RRWbJnmYZSVPaMwM6O0HwX4QSYf+/7XdiU4TpY4R68jKCQmzr+5EcZBp xb6dbb4YDsMh4cqYQZrPqw+rVy3BbZ6aG6JtdX1ZJAq0qQtyOgNBHr1GbrIfiw== X-Migadu-Scanner: scn1.migadu.com X-Migadu-Spam-Score: -1.64 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=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" X-Migadu-Queue-Id: 716B6164B3 X-Spam-Score: -1.64 X-TUID: KEoyF0PhGrSu --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi Maxim, Maxim Cournoyer writes: > As discussed previously in this thread, a good policy would be to > suggest avoid *both* rebases and merges during a feature branch > development. This way we avoid both problems, I read the whole thread and AFAIU the (only?) problem with the "merging master to feature branch" workflow is the one pointed out by Andreas [1]: =2D-8<---------------cut here---------------start------------->8--- Well, we used to repeatedly merge the master branch to core-updates, which if I remember well makes the master commits end up first in "git log". So the core-updates specific commits gradually disappear below thousands of master commits. So this is a problem. =2D-8<---------------cut here---------------end--------------->8--- So, if I don't get wrong, the only problem is with "git log" not clearly showing the commit that are specific to the feature branch: are we sure is there no option that can help feature branch reviewers focus on the specific commits? Is not "git log --no-merges master..branchname" supposed to do what we need? Or "git log --first-parent "? (not tested) > and if the branch is short lived, it should be bearable that is isn't > synced with master for its short lifetime. What lifetime is short lived in Guix context? 5 days, 3 weeks? Anyway, I'm not sure that the branches designed on Guix (i.e. those listed on https://qa.guix.gnu.org/) will be short lived, I guess some could be long lived (months instead of weeks) WDYT? Ciao, Gio' [1] id:ZIcZ9tUidrWOfgyN@jurong =2D-=20 Giovanni Biscuolo Xelera IT Infrastructures --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQJABAEBCgAqFiEERcxjuFJYydVfNLI5030Op87MORIFAmSR3rQMHGdAeGVsZXJh LmV1AAoJENN9DqfOzDkSaJsQAKlmDm07QDIE7/vlZCJeTIkbZmfjOXWvB0BsUSBZ dT+8+5+dZS7f/MbIo6c62rNZBqtsmxU9gjh/h972EGrEi6UqxgCDrReOYOyxsMM3 B18K3YFazNpqivgKCjfPXkwDHQUQ/MJm4MVerMI90AmHNIyzVQ2UXusSEIHH1wXf jwBYhTd0bxWxreZ1zZ2pDWhn3+B5JjV/NKX64gBOnroS3KdM6Fi5ZyIUWkLt9fLZ 7F/OCH0EUnjjKAJtCG/H68BZakcQZ7inVlhQrT5Q6V8RKpUIlu0wQIU+pNGZrhAX vjb1fVUPUhE9NrsFbGZjy6kAHtCyuaCbAEoK9EzlcSW1KbaiPqKfbGSLRzt2vq4z KsjuaXhO5xa/gnhw/MIZxuoWFS8RvfZnHPUm5y+XhCPUWuueYjAj0LxyuR4kvciF bCUgyXaUfCdVCMoU+DekdhE95VAsZJZNBI2CwFPQdn4v0u0qZcTP1g8M3Hr3gBvY o4lu/HAxhiWmArVbHKIzCgn08CbVrQYWkZV7aWX++4jBGtZzZJOHfZCQz3OD6Rh4 aZino7fULRVnBhYfUvy8KDfj2WsNGGvnJPRf7eH7Kft+pyxlZ68mMBWHkX8EzmSM JQb8YiBSFRY1ca8YBjMZNfFWSB2Y6SAkNCdUZWweC5GFJ7ULiKgO/ZweNb1ZZ5Xs kjKt =gLWY -----END PGP SIGNATURE----- --=-=-=--