On Tue, 2016-01-05 at 10:03 -0800, Junio C Hamano wrote: > David Turner <dtur...@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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
