Thread (1 message) 1 message, 1 author, 2017-02-08

Re: [PATCH 2/2] worktree.c: use submodule interface to access refs from another worktree

From: Junio C Hamano <hidden>
Date: 2017-02-08 23:19:55

Stefan Beller [off-list ref] writes:
On Wed, Feb 8, 2017 at 3:31 AM, Nguyễn Thái Ngọc Duy [off-list ref] wrote:
quoted
(**) 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).
I agree with you that the concept of remote is quite detached from
the concept of wt and submodule whose refs need to be peeked at from
the local repository.  After all, "remote" tracking branches are
part of local repository's refs.
My gut reaction would be to s/submodule/alternative/ here,
but we also have a thing called alternates already.
... and I tend to think that is far closer a concept.  You borrow
objects from your alternate object store, and that alternate object
store may have its own set of refs you would need to peek when you
are computing reachability from refs.

Also don't we already enumerate such refs that pin objects in the
alternate object store when doing object transfer negotiation in
order to send ".have" entries for their tips?  What API do we use to
do that, I wonder.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help