On Fri, 2015-12-11 at 15:52 -0800, Junio C Hamano wrote:
> David Turner <dturner@xxxxxxxxxxxxxxxx> 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.
--
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