On 06/02/2016 12:08 PM, Duy Nguyen wrote: > 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"? My preference is that there is a way to say "create a ref_store object representing the loose references stored physically under "$GIT_DIR/worktrees/xxx". Then that ref_store could be asked to read its `HEAD` (or iterate over all of the refs under that path or whatever). You could even write `HEAD` through the same ref_store. Michael -- 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