On Mon, May 30, 2016 at 2:55 PM, Michael Haggerty <mhagger@xxxxxxxxxxxx> wrote: > Currently, the API for iterating over references is via a family of > for_each_ref()-type functions that invoke a callback function for each > selected reference. All of these eventually call do_for_each_ref(), > which knows how to do one thing: iterate in parallel through two > ref_caches, one for loose and one for packed refs, giving loose > references precedence over packed refs. This is rather complicated code, > and is quite specialized to the files backend. It also requires callers > to encapsulate their work into a callback function, which often means > that they have to define and use a "cb_data" struct to manage their > context. > > The current design is already bursting at the seams, and will become > even more awkward in the upcoming world of multiple reference storage > backends: > > * Per-worktree vs. shared references are currently handled via a kludge > in git_path() rather than iterating over each part of the reference > namespace separately and merging the results. This kludge will cease > to work when we have multiple reference storage backends. Question from a refs user. Right now worktree.c:get_worktrees() peeks directly to "$GIT_DIR/worktrees/xxx/HEAD" and parses the content itself, something that I promised to fix but never got around to do it. Will we have an iterator to go through all worktrees' HEAD, or will there be an API to say "resolve ref HEAD from worktree XYZ"? -- Duy -- 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