Re: [PATCH 04/16] refs: add do_for_each_per_worktree_ref

[David Turner <dturner@twopensource.com>]

On Fri, 2015-12-11 at 15:52 -0800, Junio C Hamano wrote:
> David Turner <dturner@twopensource.com> writes:
> 
> > Alternate refs backends might still use files to store per-worktree
> > refs.  So the files backend's ref-loading infrastructure should be
> > available to those backends, just for use on per-worktree refs.  Add
> > do_for_each_per_worktree_ref, which iterates over per-worktree refs.
> 
> Is this "might still use"?  I am instead getting an impression that,
> we are declaring that the recommended way to store per-worktree refs
> is with filesystem backend.
> 
> Not complaining against either such a design decision (if that is
> what is made here) or the above description in the log message--just
> want to understand the intention better.

I'm not super-happy with the notion of splitting data across backends;
it's a bit messy.  I've resigned myself to it because it seems like the
simplest way forward in the presence of per-worktree refs.  But I
figured the message could leave it open in case we change our minds.

> I also wonder if it is cleaner to have a single interface that lets
> anybody ask a pointer to the backend struct by name.  With such an
> interface, a new backend that wants to delegate per-worktree refs to
> files backend could
> 
> 	static int DB_for_each_ref(...)
>         {
> 		struct ref_be *files = locate_ref_backend("files");
> 		files->for_each_ref(... | WORKTREE_ONLY, ...);
> 		... do its own enumeration of non-per-worktree refs ...
> 	}
> 
> and such a delegation does not need to be limited to per-worktree
> iteration.
> 
> Or is that a road to expose too much implementation details of
> a backend to other backends?

Given that the files backend is special in terms of its rights and
responsibilities, I think it's OK to just refer to it directly.  I think
allowing backends to generally pick and choose bits from other backends
would be confusing.