On Fri, Jul 31, 2015 at 8:59 PM, Michael Haggerty <mhagger@xxxxxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html