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 14:03:36 +0100 Message-ID: <87mtp0l7x3.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> <87zgt0biz0.fsf@randomsample> 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="23301"; 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, sir@cmpwn.com, monnier@iro.umontreal.ca, dgutov@yandex.ru, Eli Zaretskii , larsi@gnus.org To: David Engster Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Aug 29 15:07:39 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 1mKKXA-0005kh-36 for ged-emacs-devel@m.gmane-mx.org; Sun, 29 Aug 2021 15:07:36 +0200 Original-Received: from localhost ([::1]:51344 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mKKX8-0003dF-0F for ged-emacs-devel@m.gmane-mx.org; Sun, 29 Aug 2021 09:07:34 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56064) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mKKTP-00082g-Oy for emacs-devel@gnu.org; Sun, 29 Aug 2021 09:03:43 -0400 Original-Received: from mail-wr1-x42a.google.com ([2a00:1450:4864:20::42a]:45670) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mKKTO-0007AK-35; Sun, 29 Aug 2021 09:03:43 -0400 Original-Received: by mail-wr1-x42a.google.com with SMTP id n5so18105894wro.12; Sun, 29 Aug 2021 06:03:41 -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=vBv5a2cju1raMPM/2zcaCzntRxuESXDWi2TZqSTb9u4=; b=S5stPVLFchTjByrtTbhkXeH+kURU5fFqz3UwYhjH1+X3jQd+I9KtDliS4xE7vbASZL aZZO4IM1sD6TRJYwRNkyVFXeAMiwV5HWGn99QjlCS2j7YMEqgijiXBn6eFq+5NgpXMz9 UVKy0xavKsvJRgKcB/glJ2TUNWreiQz73Q55v4n7fZrXeKxlL6rXkCIOpAxiJOh3kahp vpZfnFueMrjZF71O3c6xfYM5REnAJ9GIf3816tgWuaKBKdRqS/1lUxY3D1axgi/vRekW WbWNpb2RBmdO6cVPuJZF0kNxrXFrfxTXrZhMeQcZujSSGTtsVwkelstYjuwJihOgz2t8 Aq3Q== 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=vBv5a2cju1raMPM/2zcaCzntRxuESXDWi2TZqSTb9u4=; b=sk1PCKTCVpPAVTWohP3vXiH6tUkNm8IihWZP3X1mMrDwn3wo9dKiZH8mK8BKv9SRCb Go34J3QoMiwHH4tj3FbRY3LNhlExpxkOEML1emT5cno59ckQHcc4Rh50CaPQ5EBGRYMq hnCA0gAcsmMNhibeoHxt3gJj3xKTBhpA0KAVD+3+MW0c+AcSdV1PhqvctaD43bYPUg6R 1Rp3WBrIpxx10GM8PUvDvjUWIbeVQuJEUciobMYkI1pygnhhHWO2DpglQCA0OAdPMtaW hibyBjwHocMozKueKSR1U8P9pXAL7QZRRGyKrRYiTycpZSONf9Q6HMSoCGZ3ViolIbu0 NFtA== X-Gm-Message-State: AOAM531TirhKjuZLxcJW+qvyuoaSj9RwJ7ua6ShSUVRtLsDN7uxb0yDE Vdd+mWw08rrxJVVDFNalGZ8= X-Google-Smtp-Source: ABdhPJxvZgA+uNau6/9iUpCkbKMw7Fq1/WTKJqYq7pcnqJlqoT602Un/g7+yIzHlPsXGwTb7ROXBTQ== X-Received: by 2002:adf:c54a:: with SMTP id s10mr20964206wrf.405.1630242219612; Sun, 29 Aug 2021 06:03:39 -0700 (PDT) Original-Received: from krug (a94-133-55-158.cpe.netcabo.pt. [94.133.55.158]) by smtp.gmail.com with ESMTPSA id k25sm13091970wrd.42.2021.08.29.06.03.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 29 Aug 2021 06:03:38 -0700 (PDT) In-Reply-To: <87zgt0biz0.fsf@randomsample> (David Engster's message of "Sun, 29 Aug 2021 13:14:59 +0200") Received-SPF: pass client-ip=2a00:1450:4864:20::42a; envelope-from=joaotavora@gmail.com; helo=mail-wr1-x42a.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:273407 Archived-At: David Engster writes: >>> 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 = tests ... >> >> 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 Jo=C3=A3o is confused how you would "skip" a commit in a merge, > because you actually can't. Precisely, though I'm reasonably aware of why and how its done. I've explained what I find "confusing" or "peculiar" about it in a longer email to Esli. >The more proper way would be to say "this > commit was separately merged with the strategy 'ours'", but this is > quite a mouthful. The merge stategy 'ours' simply means that the content > of the merged commits is discarded, but it's a perfectly valid way to > merge, so nothing "evil" about it. I think "evil" as an adjective is suitably exaggerated to characterize merges where some semantic knowledge of the source (vs Git's purely formal knowledge) of it, was applied to solve a particular definition of a "conflict". Those definitions and semantic insights differ from the Git defaults, which is concerned with line ranges and hunks. Newcomer Git archeologists thus don't have good way to know what kind of merge they're looking at, short of reading commit messages carefully and or perusing project documentation. Moreover the non-defualt merge techniques may be inconsistently applied across commiters or across time spans. In short, this Fear-Uncertainty-Doubt is what could be called "evil" in a sense. Of course, if everybody has a full understanding of practices, and definitions and behaves and follows rules, no FUD exists and nothing "evil" ever takes place. But that is a big "if". Jo=C3=A3o PS: the 'man gitglossary' definition of an "evil merge" is "a merge that introduces changes that do not appear in any parent." I do think this comprises "removing code that appears in some parent", because that removal is the introduction of a change that was absent before the merge commit and present after it. Linus Torvalds definition is more sophisticated and better, IMO. According to [1], he says: an "evil merge" is something that makes changes that came from neither side and aren't actually resolving a conflict. In this definition, the concept of "conflict" appears. Depending on how you massage that concept, nothing is evil and everything is.