From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gregory Heytings Newsgroups: gmane.emacs.devel Subject: Re: Emacs git repo mangled Date: Tue, 01 Nov 2022 13:55:09 +0000 Message-ID: <48c054670f6a015a2cca@heytings.org> References: <87v8o0hrk2.fsf@gmx.de> <88f2ba22-64c4-c835-294e-9367766161e5@gmail.com> <87bkprhw7r.fsf@gmx.de> <48c054670f70ff7b056a@heytings.org> <877d0eiywf.fsf@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14145"; mail-complaints-to="usenet@ciao.gmane.io" Cc: =?UTF-8?Q?Gerd_M=C3=B6llmann?= , emacs-devel@gnu.org To: Michael Albinus Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Nov 01 18:28:28 2022 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 1opv3r-0003QU-Db for ged-emacs-devel@m.gmane-mx.org; Tue, 01 Nov 2022 18:28:27 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oprje-0005Lw-DD; Tue, 01 Nov 2022 09:55:22 -0400 Original-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 1oprja-0005LR-EE for emacs-devel@gnu.org; Tue, 01 Nov 2022 09:55:18 -0400 Original-Received: from heytings.org ([95.142.160.155]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oprjW-0002pK-Ob for emacs-devel@gnu.org; Tue, 01 Nov 2022 09:55:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1667310910; bh=OWNTLXoIT+4/UxKoCDKXiDZz5lSCN/Smgw9PNIxj4dw=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=e+sZcll3/NaZPN5fLTkXVfRt2+TBPdLnCOI1CHziqovKbC/dsgePW5j/99YA9WVxz r9JeAQAZcJRip4e3yvEM52grDhw7c5bjLTR+4uVYC9j0YiM6tf1NqvleYouJAvpOJ0 gS0Etb/BRHeeyFlbINn4hKu1dQwEf4yxl/X4f4vCBmyM6hya/i26XE4vPJJ52eK/R6 3iHo6kz+KlfODBzaJSxgatodJGfr751k26NvezZ7xyGAT507/BufyBLrgsFETepjb/ 2YntYRUmLjCnBnjpcqtYSw0LBghlwBSoDc3NLjAZZI4eAWpHbYomHaqDLuYQ/UTy18 3N4C2xni9nllQ== In-Reply-To: <877d0eiywf.fsf@gmx.de> Received-SPF: pass client-ip=95.142.160.155; envelope-from=gregory@heytings.org; helo=heytings.org 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, SPF_HELO_PASS=-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.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: "Emacs-devel" Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:298960 Archived-At: >> Doing that is wrong, alas. Limiting bisection to first parents will >> often produce a wrong result. TRT here is to follow Linus' advice, to >> which I pointed in my other post, namely to manually mark the last >> commit of the eglot branch before it was merged as "good". > > This approach would raise other problems. > > - You might not know that you are in a merged subtree. It took me two > days until I realized this (hmm, this could mean I'm too stupid). > I don't know what happened exactly, but the Eglot tree has another root, so when you are inside that branch you should not see any of the files that are part of the Emacs tree (e.g. "Makefile" and "configure"). What was the cause of your confusion? > > - If the bad commit is inside the merge, you won't see it, because you > have marked the whole merged subtree as good (by marking the last commit > of the merged subtree). > By definition, the bad commit cannot be inside the merged Eglot tree, because that three contains only Eglot, not Emacs. It bad commit could be the merge commit, but that one is not excluded during the bisection if you mark the last commit before the merge as "good". > > - It would require manual actions, because first you need to determine > the range of the merged subtree in order to mark last commit of this. > That is correct, and it is the price to pay to preserve history when a tree with another root is merged. Perhaps we could maintain a list of such merges somewhere, with the commit SHA of the last commit before each merge. Or perhaps even a commented script, that would do a "git bisect good ..." for each such commit.