Re: Emacs git repo mangled

[Gregory Heytings <gregory@heytings.org>]

>> 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.