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

[David Turner <dturner@twopensource.com>]

On Fri, 2015-07-31 at 22:12 -0700, Junio C Hamano wrote:
> 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.

Agreed, I think it's a mistake to complicate the global ref namespace
like that.

> 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?

We still need the packed-refs and is_per_worktree_ref change; we need a
different and more complicated loose-refs loading change, and we need
changes to path.c to treat refs/bisect different from refs/.  Probably a
few dozen lines, yeah.  And it's sort of ugly to make the refs/bisect
special case into a fundamental part of the repository structure.  

I'm worried that we'll discover a need for more of these.  But I can do
the rewrite and see how it looks (probably on Monday).

Do we need to worry about reflogs for these?  If so, a few more lines,
probably.

> 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.

Yes, this is a good point.