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

From: David Turner <dturner@twopensource.com>
Date: Dec 12, 2015, 00:01 UTC
Message-ID: <1449878510.1678.7.camel@twopensource.com>
In-Reply-To: <xmqqio44czm1.fsf@gitster.mtv.corp.google.com>

On Fri, 2015-12-11 at 15:52 -0800, Junio C Hamano wrote:

Show 14 quoted lines

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

Show 17 quoted lines

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