[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs git repo mangled

From: Gregory Heytings
Subject: Re: Emacs git repo mangled
Date: Tue, 01 Nov 2022 13:55:09 +0000

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]