On Tue, Jan 23, 2024 at 09:44:21AM -0800, Junio C Hamano wrote: > 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. Yes, "bisect-state/" would need to be stored in GIT_DIR, not COMMON_DIR. > > 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"). We also have consider that there may be alternate implementations of Git that would only know to handle the old layout. Those tools would be broken in case we did such a migration, but they would be broken anyway if the bisect was started via Git and not via the tool. Anyway, I'll add this to our growing backlog of issues that we might want to investigate once the reftable backend has been upstreamed. Which of course shouldn't preclude anybody else from picking up this topic in case they are interested. Patrick
Attachment:
signature.asc
Description: PGP signature
