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

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 8, 2017, 23:19 UTC
Message-ID: <xmqqvasktgmj.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <CAGZ79kZk1Chq1R-anz0RC+0GDEubGm5kEQOsy5bz9zwCYEi9nw@mail.gmail.com>

Stefan Beller <sbeller@google.com> writes:

Show 8 quoted lines

> On Wed, Feb 8, 2017 at 3:31 AM, Nguyễn Thái Ngọc Duy <pclouds@gmail.com> 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).

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.