Re: Re* [PATCH v2 1/2] refs: refs/worktree/* become per-worktree

On Tue, 2015-08-11 at 14:10 -0700, Junio C Hamano wrote:

David Turner [off-list ref] writes:

quoted

We need a place to stick refs for bisects in progress that is not
shared between worktrees.  So we use the refs/worktree/ hierarchy.

This is by itself OK, but to help existing Porcelains, most notably
"gitk", I think refs/bisect/ hierarchy should be treated the same
way.  Moving them out of refs/bisect/ to refs/worktree/bisect/ would
not be a good idea.

What does gitk do that's relevant here?

Because refs/worktree/ hierarchy is not needed right now, I think we
can even live with just special casing refs/bisect/ the way this
patch does, without adding refs/worktree/ support at this point.

There are a few reasons for refs/worktree hierarchy:

1. To make it easy to see the behavior of a ref at a glance.
2. To avoid too many different special-cases.

It's true that special-casing refs/bisect would make for fewer code
changes for now, but I am worried that next week we'll discover a new
situation where we'll want per-worktree refs and then we'll have to add
more special-cases.

quoted

Note that git for-each-ref may have inconsistent behavior (I think; I
haven't confirmed this), sometimes showing refs/worktree/* and sometimes
not.  In the long run, we should fix this, but right now, I don't know
that it matters, since the only refs affected are these bisect refs.

We should fix that before this hits 'master', preferrably before
this hits 'next', especially if we add support for the more generic
refs/worktree/.  If it is only for refs/bisect/, we might be OK, but
I didn't think things through.

I will do this.  Should for-each-ref include or exclude these refs?  One
simple way to do "include" is to always create the refs/worktree
directory (when creating refs/).  

I'll also fix the rest of the things you suggested.