On 02/09/2017 12:59 PM, Duy Nguyen wrote:
> On Thu, Feb 9, 2017 at 1:07 PM, Michael Haggerty wrote:
>> It is unquestionably a good goal to avoid parsing references outside of
>> `refs/files-backend.c`. But I'm not a fan of this approach.
>
> Yes. But in this context it was more of a guinea pig. I
On Thu, Feb 9, 2017 at 1:07 PM, Michael Haggerty wrote:
> It is unquestionably a good goal to avoid parsing references outside of
> `refs/files-backend.c`. But I'm not a fan of this approach.
Yes. But in this context it was more of a guinea pig. I wanted
something simple enough to code up show we
On 02/09/2017 07:55 AM, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> There are two meanings of the concept of a "ref store", and I think this
>> change muddles them:
>>
>> 1. The references that happen to be *physically* stored in a particular
>>location, for example the `refs/bisect
Michael Haggerty writes:
> There are two meanings of the concept of a "ref store", and I think this
> change muddles them:
>
> 1. The references that happen to be *physically* stored in a particular
>location, for example the `refs/bisect/*` references in a worktree.
>
> 2. The references tha
On 02/08/2017 12:31 PM, Nguyễn Thái Ngọc Duy wrote:
> The patch itself is relatively simple: manual parsing code is replaced
> with a call to resolve_ref_submodule(). The manual parsing code must die
> because only refs/files-backend.c should do that. Why submodule here is
> a more interesting ques
Nguyễn Thái Ngọc Duy writes:
> As such, we can just linked worktree's path as a submodule. We just need
Lack of verb made me read this three times. "We can just treat
linked worktree's path as if it were a submodule"?
I agree with you that the "submodule" in the name is misleading. We
would
Stefan Beller writes:
> On Wed, Feb 8, 2017 at 3:31 AM, Nguyễn Thái Ngọc Duy
> 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,
> becau
On Wed, Feb 8, 2017 at 3:31 AM, Nguyễn Thái Ngọc Duy 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 "
The patch itself is relatively simple: manual parsing code is replaced
with a call to resolve_ref_submodule(). The manual parsing code must die
because only refs/files-backend.c should do that. Why submodule here is
a more interesting question.
>From an outside look, any .git/worktrees/foo is seen
9 matches
Mail list logo
