Patrick Steinhardt <ps@xxxxxx> writes: > My first hunch was to convert it so that it indeed always is a proper > ref. But thinking about it a bit more I'm less convinced that this is > sensible as it is deeply tied to the behaviour of git-bisect(1) and only > represents its internal state. I thus came to the conclusion that it is > more similar to the sequencer state that we have in ".git/rebase-merge" > and ".git/rebase-apply" than anything else. Fair enough. > So if we wanted to rectify this, I think the most sensible way to > address this would be to introduce a new ".git/bisect-state" directory > that contains all of git-bisect(1)'s state: > > - BISECT_TERMS -> bisect-state/terms > - BISECT_LOG -> bisect-state/log > - BISECT_START -> bisect-state/start > - BISECT_RUN -> bisect-state/run > - BISECT_FIRST_PARENT -> bisect-state/first-parent > - BISECT_ANCESTORS_OK -> bisect-state/ancestors-ok > > I think this would make for a much cleaner solution overall as things > are neatly contained. Cleaning up after a bisect would thus only require > a delete of ".git/bisect-state/" and we're done. And bisect-state/ needs to be marked as per-worktree hierarchy, I suppose. > Of course, this would be a backwards-incompatible change. As long as we ignore folks who switches versions of Git in the middle of their "git bisect" session, we should be OK. If we really cared the backward compatibility, the new version of Git that knows and uses this new layout could notice these old-style filenames and move them over to the new place under new names. From there, everything should work (including things like "git bisect log"). Thanks.
