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: Gitlab Migration Date: Sun, 29 Aug 2021 10:53:53 +0100 Message-ID: <874kb8mv9q.fsf@gmail.com> References: <8d0be260-7b15-0b48-42e5-e5a4cc203e54@yandex.ru> <837dg4n1ix.fsf@gnu.org> <834kb8mzk1.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="8576"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: "Philip K." , Daniel Fleischer , Theodor Thornhill , emacs-devel , Stefan Monnier , Dmitry Gutov , Eli Zaretskii , Lars Ingebrigtsen To: Drew DeVault Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Aug 29 11:54:38 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 1mKHWQ-00022M-BO for ged-emacs-devel@m.gmane-mx.org; Sun, 29 Aug 2021 11:54:38 +0200 Original-Received: from localhost ([::1]:48128 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mKHWO-0007D0-TR for ged-emacs-devel@m.gmane-mx.org; Sun, 29 Aug 2021 05:54:36 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34620) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mKHVp-0006YD-5t for emacs-devel@gnu.org; Sun, 29 Aug 2021 05:54:01 -0400 Original-Received: from mail-wr1-x42d.google.com ([2a00:1450:4864:20::42d]:38485) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mKHVn-0007jx-JU; Sun, 29 Aug 2021 05:54:00 -0400 Original-Received: by mail-wr1-x42d.google.com with SMTP id u16so17727219wrn.5; Sun, 29 Aug 2021 02:53:58 -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=Qw3yntKuDbI/iPHlaGf7WXHLjrm2IIXGAaQw0ZJTj+g=; b=hPhZFXmHfNSJ+zn9+JzzM3vgQyDngaOlAb3CAnI9FoJ+HdgpTskASBVUBpXi5hqJo+ iOdtsu0FG85Jg6dn1g0hIPb+zAXR/CgLfdWTOj4943gLB8IJbLrd1e11hkyBP+x/XGI1 6j7O0WJEKdGF0H2McorcbM4H9odtkEg8mx8ixP7OFPZr/YGFzHEZhLm1BxxIvAigTbYq Uv7fL7m4z2SZM8jlFFZDFfXV5IkjI13NNMofamJ0peLKdmOV4ondtgUqb/yg0cDBqH4+ NkRAy2Rd36LMT3hSCearFuJKlvz04besr91KukFj4zC6hROn5Hq/2ugbCAzlfsAcMh44 pR9w== 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=Qw3yntKuDbI/iPHlaGf7WXHLjrm2IIXGAaQw0ZJTj+g=; b=iJmkRvKcQ7rrcnzDSl8/YngoWrQcrYmRFOGaUwQqEmeCRgVBNGhbNhWmAgZtUoBa0l fCiBsOVhiWabutOC40TtoErNguEmt6YniAPW0iW9+lTckMdkMgBrRUK8Tz/pd5fnviDr 8gY75lwMQhaPeUdUdULerBZXBFI1efLex6TmC3uG5jrD3T+fYpB5HwUUbNKJ2llyvqzS p41ob8Vrp/Hk5jeqRJVqKVOhlD6hM/8jZw2ekTub4SzJI1Zwbo+l43v0Pr6UMDWHBJ+E hW/3d5SnJd6hk+4x9GSHpyEQsrrObCv1NEoMGiz9+QkyNMIb7AGzWuDOJhswDgbsCdu6 HbJg== X-Gm-Message-State: AOAM530HvCWFwk3EBM5svjqKQUU7B6qK274/bKQEdpHiWJ8AHzpeymBj vD0J1vp9hIoN3UNYaSgx7ck= X-Google-Smtp-Source: ABdhPJzv+q/LCmxo24TbIMfpbzRjl8ln92uRZqzuXLxnr6kivmIaktR3jLzyXFhp1rCwBXzWkhePKg== X-Received: by 2002:adf:e68b:: with SMTP id r11mr20271234wrm.394.1630230837219; Sun, 29 Aug 2021 02:53:57 -0700 (PDT) Original-Received: from krug (a94-133-103-226.cpe.netcabo.pt. [94.133.103.226]) by smtp.gmail.com with ESMTPSA id m24sm15587734wrb.18.2021.08.29.02.53.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 29 Aug 2021 02:53:56 -0700 (PDT) In-Reply-To: (=?utf-8?Q?=22Jo=C3=A3o_T=C3=A1vora=22's?= message of "Sun, 29 Aug 2021 10:09:30 +0100") Received-SPF: pass client-ip=2a00:1450:4864:20::42d; envelope-from=joaotavora@gmail.com; helo=mail-wr1-x42d.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:273395 Archived-At: Jo=C3=A3o T=C3=A1vora writes: > On Sun, Aug 29, 2021, 09:23 Drew DeVault wrote: > > On Sun Aug 29, 2021 at 10:21 AM CEST, Eli Zaretskii wrote: > > I no longer remember the exact details, it was something we bumped > > into during discussions when Emacs switched to Git. AFAIR, it had to > > do with working on a feature branch and frequently rebasing it onto > > the latest master (so that the feature branch doesn't diverge too > > much), then later merging from the feature branch to master. > > Hm, weird. I would like to see some reproducible evidence of this so > that a deeper investigation can be done. I've used rebase thoroughly for > many years on hundreds of projects without any such incident. > > If the branch you're integrating via rebase happens to have merge > commits of its own, and you don't pass and/or fully understand what > --preserve-merges does, it's possible I think. If you always always > merge, it doesn't happen. Neither does it if you always always rebase, > I guess. So I guess the argument can be spun around into a > counter-merge argument, I guess. Anyway, I'm a rebase lover myself. I just realize I "guessed" about 50 thousand times there and was basically handwaving. I've tried a simple example of my own speculation just now and couldn't reproduce. Either my toy example was too simplistic (it involved two branches, a single file and no conflicts ever) or it's been somehow fixed in recent Git versions. I still think it may happen if you mix rebase & merge. Especially if you merge from "unreliable branches", i.e. branches whose collaborators are not entirely aware/proficient with the commit-duplicating consequences of rebasing and/or cherry-picking. 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: commit 8ba6a38b3bccab6eda8e1962e4c8618704b9f83e Merge: 979f14e641 5b03849102 Author: Glenn Morris Date: Wed Aug 25 07:51:41 2021 -0700 =20=20=20=20=20 ; Merge from origin/emacs-27 =20=20=20=20=20 The following commit was skipped: =20=20=20=20=20 5b03849102 (origin/emacs-27) ; * test/lisp/files-tests.el: Add test= s ... I don't know if this practice is what constitutes an "evil merge", but it's the way Emacs release management has worked (successfully, to the best of my knowledge) for a good while. Jo=C3=A3o