On Mon, 2015-08-03 at 20:55 +0700, Duy Nguyen wrote: > On Fri, Jul 31, 2015 at 1:06 PM, David Turner <dturner@xxxxxxxxxxxxxxxx> wrote: > > Add a function ref_type, which categorizes refs as per-worktree, > > pseudoref, or normal ref. > > For per-worktree refs, you probably should follow common_list[] in > path.c because that's how file-based ref namespace is splitted between > per-repo and per-worktree, even though just as simple as "everything > outside refs/ is per-worktree" (with an exception of NOTES_MERGE_REF, > which should be on the list as well). At least the two should be > aligned so that the default file-based backend works the same way as > new backends. That would be cleaner, I think. I'm maybe a little worried about performance if we do this, but I guess we could optimize later. Before I re-roll, I'll wait until we come to a conclusion on the other per-worktree ref thread. I think we discussed NOTES_MERGE_REF[1], and decided that it should work like HEAD. Does that seem right to you? > Going further, I think you need to pass the "worktree identifier" to > ref backend, at least in ref_transaction_begin_fn. Each backend is > free to store per-worktree refs however it wants. Of course if I ask > for refs/foo of worktree A, you should not return me refs/foo of > worktree B. ref_transaction_begin_fn can return a fault code if it > does not support multiple worktrees, which is fine. If we did that, we would have to add it all over the place -- not just ref_transaction_begin, but also update_ref. I think it's better to encapsulate this knowledge inside the refs code. > > Later, we will use this in refs.c to treat pseudorefs specially. > > Alternate ref backends may use it to treat both pseudorefs and > > per-worktree refs differently. > > I'm not so sure that this can't be hidden behind backends and they can > have total control on falling back to file-based, or store them in > some secondary storage. I haven't re-read your discussion with Junio > yet (only skimmed through long ago) so I may be missing some important > points. The worry is symbolic refs -- a symbolic ref might be a per-worktree ref pointing to a shared ref pointing to a per-worktree ref. This is why it's simpler to let backends handle things. If we had some rules about this, we could maybe hide this from the backend, but so far, this was the simplest thing to do (it works great!). [1] http://www.spinics.net/lists/git/msg256793.html -- 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