Re: [PATCH/RFC 0/2] bisect per-worktree

[Junio C Hamano <gitster@pobox.com>]

On Fri, Jul 31, 2015 at 8:59 PM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
>
> It seems to me that adding a new top-level "worktree-refs" directory is
> pretty traumatic. Lots of people and tools will have made the assumption
> that all "normal" references live under "refs/".
> ...
> It's all a bit frightening, frankly.

I actually feel the prospect of pluggable ref backend more frightening,
frankly ;-). These bisect refs are just like FETCH_HEAD and MERGE_HEAD,
not about the primary purpose of the "repository" to grow the history of refs
(branches), but about ephemeral pointers into the history used to help keep
track of what is being done in the worktree upstairs. There is no need for
these to be visible across worktrees. If we use the real refs that are grobal
in the repository (as opposed to per-worktree ones), we would hit the backend
databas with transactions to update these ephemeral things, which somehow
makes me feel stupid.

I wish we could just make refs/bisect/* (or whatever the current bisect
code uses) automatically per worktree. I know David dismissed it saying
that the current code is not set up to allow it easily, but is it
really a fundamental
limitation, or is it just a matter of coding a few more dozens of lines?

If we can keep using the same location under refs/ and transparently make
them appear per-worktree, "what is the name of the main one?", and "do we
even need to call the one and the only one 'main'?" will automatically
disappear.
Of course, "git bisect" and "gitk --bisect" does not have to change if
we go that
route.

And there will not be any backward compatibility worries. If you are not
using multiple worktrees, you will see them as refs/bisect/*, just at the
same location as you are familiar with.