On Wed, Feb 8, 2017 at 3:31 AM, Nguyễn Thái Ngọc Duy <pclouds@xxxxxxxxx> wrote:
> (**) At this point, we may want to rename refs *_submodule API to
> something more neutral, maybe s/_submodule/_remote/
I agree on (**), except that I am not sure if /_remote/ is a better name,
because there is already a concept of a "remote" as well as
"remote-tracking" in Git. (Usually it is not reachable on the same
FS, but resides on another machine).
So if we were to do s/_submodule/_remote/, we'd have e.g.
for_each_ref_remote
which could mean that we do networking things to obtain the
actual remote refs or just talk about remote tracking refs.
My gut reaction would be to s/submodule/alternative/ here,
but we also have a thing called alternates already.
So we're looking for a name that describes refs for both
worktrees as well as submodules. (Not sure if we can generalize
to also include alternates, too)
And the one thing they share is that they have their refs
"not at the usual place", e.g. not at .git/refs but rather at
.git/{modules,worktrees}.
Recently we had a tangential discussion in submodule land
about the different places, when adding the
"git submodule absorbgitdirs" command, that moves
the submodule/.git directory into .git/modules/<name>.
We chose "absorb" here as the name, because it
was moved into the .git/ area.
So maybe one of:
s/submodule_ref/unusual_ref/
(to emphasize it is not a regular ref inside the repo, so:)
s/submodule_ref/irregular_ref/
s/resolve_ref_submodule/resolve_ref_out_of_place/
s/resolve_ref_submodule/resolve_ref_gitlink_pointed/
s/resolve_ref_submodule/resolve_ref_linked_pointer/
would be my current thinking.
Thanks,
Stefan