On Mon, Mar 20, 2017 at 9:25 PM, Michael Haggerty wrote:
> Instead of moving all of the `for_each_*_submodule()` functions over, I
> encourage you to consider getting rid of them entirely and let the
> end-users call the `refs_for_each_*()` versions of the functions. Again,
> I'm not sure that the
On 03/20/2017 01:01 PM, Duy Nguyen wrote:
> On Mon, Mar 20, 2017 at 1:59 PM, Michael Haggerty
> wrote:
>> I guess I can hold my nose and accept storing worktree and submodule
>> `ref_store`s together in a single hashmap
>
> Release your nose, I'll add a new hashmap :)
Thanks :-)
> But while we
On Mon, Mar 20, 2017 at 1:59 PM, Michael Haggerty wrote:
> I guess I can hold my nose and accept storing worktree and submodule
> `ref_store`s together in a single hashmap
Release your nose, I'll add a new hashmap :) But while we're here,
what are your thoughts about moving submodule-specific to
On 03/18/2017 11:02 AM, Nguyễn Thái Ngọc Duy wrote:
> files-backend at this point is still aware of the per-repo/worktree
> separation in refs, so it can handle a linked worktree.
>
> Some refs operations are known not working when current files-backend is
> used in a linked worktree (e.g. reflog)
files-backend at this point is still aware of the per-repo/worktree
separation in refs, so it can handle a linked worktree.
Some refs operations are known not working when current files-backend is
used in a linked worktree (e.g. reflog). Tests will be written when
refs_* functions start to be call
5 matches
Mail list logo
