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