David Turner [off-list ref] 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.
On Tue, 2016-01-05 at 10:03 -0800, Junio C Hamano wrote:
David Turner [off-list ref] writes:
quoted
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.
On 01/05/2016 07:03 PM, Junio C Hamano wrote:
David Turner [off-list ref] writes:
quoted
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.
...whereas whatever we name the option, we have to live with forever
because it is user-facing. It's more important to get the option name
correct (though I agree that it would be nice for the nomenclature used
in the code to be reminiscent of the option name).
Michael
--
Michael Haggerty
mhagger@alum.mit.edu