Re: [PATCH 13/16] init: allow alternate backends to be set for new repos

[David Turner <dturner@twopensource.com>]

On Tue, 2016-01-05 at 10:03 -0800, Junio C Hamano wrote:
> David Turner <dturner@twopensource.com> writes:
> 
> > I'm working on the rest now, but wanted to comment on this first. 
> >  I
> > went ahead and made this change, but I'm not sure I like it.  In
> > the
> > git codebase, the concept will continue to be called "backend";
> > there
> > are already-accepted patches using that terminology.  Having two
> > separate names for the same thing seems confusing to me.
> 
> We have the option to update whatever "are already-accepted" [*1*].
> That would allow us to uniformly call it "ref storage", if we wanted
> to.
> 
> In any case, we shouldn't be using an unqualified "backend" (or
> "storage" for that matter); we should always say "ref", i.e. either
> "ref backend" or "ref storage", in the name.
> 
> Between "backend" and "storage", I am slightly in favor of the
> latter, but I am not good at naming things so...
> 
> 
> [Footnote]
> 
> *1* Output from
> 
>     $ git grep backend master --
> 
> seems to show me only 
> 
>     master:refs.c: * The backend-independent part of the reference
> module.
> 
> and all others are other kinds of backends, e.g. "merge backend",
> "http-backend", etc. so that may not be too bad.

There's refs/files-backend.c in master.

I guess the argument for "backend" is that it is a better description
of the struct.  That is, "a storage" sounds funny.  Usually "storage"
is a mass noun.  I guess we could call them "storage backends" (with
"ref-storage" in the UI), which would split the difference.  I guess
I'll go with that, and we can decide later whether to rename those
files.