On Mon, Nov 13, 2023 at 09:42:09PM +0100, Janik Haag wrote: > Thank you for filling out a Git bug report! > Please answer the following questions to help us understand your issue. > > What did you do before the bug happened? (Steps to reproduce your issue) > ```bash > git init /tmp/reproduce-bisect-warning > cd /tmp/reproduce-bisect-warning > touch .git/BISECT_LOG > git bisect reset > git switch -c log > ``` > > What did you expect to happen? (Expected behavior) > > `git-bisect reset` should have deleted .git/BISECT_LOG > > What happened instead? (Actual behavior) > > .git/BISECT_LOG is still there I don't think this is really specific to BISECT_LOG. In "bisect reset", we'll call bisect_clean_state(), which removes a bunch of files. The problem in your example is that "bisect reset" sees that we are not bisecting and bails early. Which I can kind of see, as part of the "reset" process is to reset to the original pre-bisect commit. If it's not given on the command line, the default is to use BISECT_START, which of course does not exist. As a side note, "git bisect reset HEAD" will do what you want, because it skips the BISECT_START check. But obviously that's not something normal users should need to know about, and I think is even an accidental side-effect of the conversion in 5e82c3dd22 (bisect--helper: `bisect_reset` shell function in C, 2019-01-02). So really, you just want the "clean" part of "bisect reset", but not the "reset". We could have a separate "bisect clean" that would do what you want (clean state without trying to reset HEAD). But I don't think it would be unreasonable to "reset" to just unconditionally clean. I think it would probably just be a few lines in bisect_reset() to avoid the early return, and skip the call to "checkout" when we have no branch to go back to. Maybe a good simple patch for somebody interested in getting into Git development? -Peff
