Gregory Heytings <gregory@heytings.org> writes: Hi Gregory, > 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? Exactly this: all files were lost, I thought. I'm not so fluent with git, and so I did panic. >> - 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". That's the eglot case. I was speaking about a merge in general. >> - 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. Sigh. > 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. Don't know, I let it to the git aficionados. Best regards, Michael.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4