From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= Newsgroups: gmane.emacs.devel Subject: Re: Merges from release branch Date: Sun, 29 Aug 2021 13:29:27 +0100 Message-ID: <87r1ecl9i0.fsf@gmail.com> References: <8d0be260-7b15-0b48-42e5-e5a4cc203e54@yandex.ru> <837dg4n1ix.fsf@gnu.org> <834kb8mzk1.fsf@gnu.org> <874kb8mv9q.fsf@gmail.com> <83tuj8ldgi.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22033"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: philipk@posteo.net, danflscr@gmail.com, theo@thornhill.no, emacs-devel@gnu.org, monnier@iro.umontreal.ca, dgutov@yandex.ru, larsi@gnus.org, sir@cmpwn.com To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Aug 29 14:32:31 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mKJzA-0005Rb-Mo for ged-emacs-devel@m.gmane-mx.org; Sun, 29 Aug 2021 14:32:28 +0200 Original-Received: from localhost ([::1]:57712 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mKJz8-0003rQ-TG for ged-emacs-devel@m.gmane-mx.org; Sun, 29 Aug 2021 08:32:26 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51990) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mKJwQ-00032T-Th for emacs-devel@gnu.org; Sun, 29 Aug 2021 08:29:39 -0400 Original-Received: from mail-wm1-x336.google.com ([2a00:1450:4864:20::336]:38904) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mKJwP-0002GR-2U; Sun, 29 Aug 2021 08:29:38 -0400 Original-Received: by mail-wm1-x336.google.com with SMTP id d22-20020a1c1d16000000b002e7777970f0so12659670wmd.3; Sun, 29 Aug 2021 05:29:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=tzCVLhGbn1RY8kE0FqqWURMmAJVQqIbMR6YXdz4X9GI=; b=ZVWooKBYRZFZeeaH2EiE79OGgkqtCddcLiJjaTdClHq7AXoXM87FPfG0vz3B/NoRwM zxabHCmBvJ+rR0/lSZHi2BTm/L3wCyqvEo9VvSJaWsmeQUHBdzhI0Z1hfgU7+YRC0axv sCEhFMZSxgx1vlfHPd6D6MB4fvPSOFLqmXqSdAa+dXwN+b3jHiqymYh57R2CN9Y2PblS 8fiVNOQxsJMBtJJR5XsrA+sM/H1FvA01NN/gc6e5jRTG91Ncaz1qrZw5gUqvL1nJAKoj EqXckZb6qbGv4mf991dZ9W9keLQuyBwmx3HX+BybPeUW+TTKypAOY0JGVP7mAHHWlPAZ TwRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=tzCVLhGbn1RY8kE0FqqWURMmAJVQqIbMR6YXdz4X9GI=; b=SHY9hb0NZJmZdIhHQDcffrqkBK/2fEoA8t4/kLjOzyHYRVyt/Jtdvrr48y3TEv8qON vqAsqYPyZj9zopvfk4WauNYt7rHsx8V7rzvdKBPA71xm1Qf0L2h3J1c6zU6sv9oQcVXb 5Ui9/f1+s1urHQKtf7DiOcrE+ZfVcSgaDrA/gCTqJy7SQEpezoPOcqojWsTVApAVG5I2 b/sNh6DZtzAMI/GqB0KGEBL1f4+Laq1cfDkHa5YA8mlPx2A8aniD6kqI5DXk9VJ+dGFu hmAsj0zOJc7RGptN4UPK0kxLMRB9MxEHe6nQDVo1C7YexsiCBz8AiBnNajShwrMUTHDY 0yDA== X-Gm-Message-State: AOAM533wXb5WBHKolccbYBWybMfTZ1J6L3tVOnHnX0V+FOVYBM752F7O zeWHLq4qx69NOmbvfS5pAcI= X-Google-Smtp-Source: ABdhPJy88kNpMWJgPIgUjDwe6ye3JDMNb7ZBL6dNONgD49xbn4IFS88pH7pyzsqOWjhnzoFEhlBzCA== X-Received: by 2002:a1c:7d44:: with SMTP id y65mr27513781wmc.6.1630240175188; Sun, 29 Aug 2021 05:29:35 -0700 (PDT) Original-Received: from krug (a94-133-55-158.cpe.netcabo.pt. [94.133.55.158]) by smtp.gmail.com with ESMTPSA id q13sm1177027wmj.46.2021.08.29.05.29.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 29 Aug 2021 05:29:34 -0700 (PDT) In-Reply-To: <83tuj8ldgi.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 29 Aug 2021 14:03:57 +0300") Received-SPF: pass client-ip=2a00:1450:4864:20::336; envelope-from=joaotavora@gmail.com; helo=mail-wm1-x336.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:273405 Archived-At: Eli Zaretskii writes: >> From: Jo=C3=A3o T=C3=A1vora >> Cc: Eli Zaretskii , "Philip K." , Da= niel >> Fleischer , Theodor Thornhill , >> emacs-devel , Stefan Monnier >> , Dmitry Gutov , Lars >> Ingebrigtsen >> Date: Sun, 29 Aug 2021 10:53:53 +0100 >>=20 >> This is a tangent, but we also have some practice here in Emacs which I >> don't fully understand, which is to "merge back from release branches" >> to integrate fixes from those branches into 'main'. That in itself >> already opens the doors to "duplicated commits" if special care isn't >> taken. That's because these merges are special: they somehow don't >> contain all of the stuff that was present in the release branches. See, >> for example, this commit: >>=20 >> commit 8ba6a38b3bccab6eda8e1962e4c8618704b9f83e >> Merge: 979f14e641 5b03849102 >> Author: Glenn Morris >> Date: Wed Aug 25 07:51:41 2021 -0700 >>=20=20=20=20=20=20 >> ; Merge from origin/emacs-27 >>=20=20=20=20=20=20 >> The following commit was skipped: >>=20=20=20=20=20=20 >> 5b03849102 (origin/emacs-27) ; * test/lisp/files-tests.el: Add t= ests ... > > What problems do you see with these merges? I don't think I follow. > > The commits are skipped either because they are marked "not to merge" > (meaning they are inappropriate for master) or because master already > has the same or a different fix. I think I understand fully the reasons _why_ they are skipped. Here's the source of my comment/confusion: normally, in a merge, I have the expectation that the ancestors of the each branch being merged become ancestors of the new commit, the "merge commit". That is the way that the vast majority of merges function. However, for Emacs's "skipped commits" it is sometimes only half-true, at best. For instance, 5b038491 is, according to Git, an ancestor of 8ba6a38b3 and all 8ba6a's descendents. However, its contents -- i.e. its diff -- are not. At least, not exactly in the diff form as they were created, because, as you say, they may take on a different form. I'll add that in the case of a bugfix commit, that bugfix may be entirely not applicable to 'main' become the root cause of the bug being fixed has been eliminated in the meantime. Then the skipped commit contents would simply not be in 'main'. Nevertheless, a naive Git archeologist will assume 5b038491 to be in 8ba6a38b3 or its descendents, but will _not_ find its contents as easily as he would some other non-skipped commit from some other regular merge. If the user is lucky, she'll reach hopefully 8ba6a38b3 and read the commit message which hopefully explains the situation: "you'd think 5b038 would be here, but it's not because reasons". In summary, the Emacs way of doing this confuses me (and perhaps other Git users), as I expect a merge commit to integrate fully the developments of two or more branches. That is, when I see it in the DAG, I expect it to contain the contents of the two or more ancestor branches. Modulo conflict resolutions, where "conflict" is defined by Git's inability to merge automatically (using whichever merge driver). Of course a project may have sophisticated drivers and/or sophisticated "semantic" definitions of "conflict" so that even Emacs's way of doing this could in a way conform perfectly to my expectation if I'm sufficently aware of those definitions. Anyway, what could be an alternative? Well, in other projects I work with, these re-integrations of "release-and-dev-worthy" fixes into the main development branch take the form of 'git cherry-pick's. In Emacs, this would mean cherry-picking only the "unskipped" commits. The cherry-picks' commit messages can be specially marked via a `-x` flag. Arguably -- though, mind you, I'm not necessarily arguing in this direction, just presenting an idea-- this is a means to: * reach the same end goal: to have the release-and-dev-worthy fixes integrated into the main branch; * provide more clarity to Git users who may not be familiar with the particular sophisticated definition of a conflict or non-default merge drivers. I've seen multiple project work in this cherry-pick fashion, but I've not done any kind of survery. I'm unaware of what the linux kernel does, for example. Emacs is the only project I know that uses merges this way, and afaik, they work fine: I've never personally had a problem with archeology. Hope this helps, Jo=C3=A3o