Nguyễn Thái Ngọc Duy <pclo...@gmail.com> writes: > A hundred years ago I added this code because a "standalone" ref > parsing code was not available from refs.c and the file was going through > some heavy changes that refactoring its ref parsing code out was not > an option. I promised to kill this parse_ref() eventually. I'm > fulfilling it today (or soon).
;-) Thanks. And thanks for looping Michael in. I'd appreciate his input in this area. > I would really like to you double check the approach I'm using here > (using submodule interface for accessing refs from another worktree) > since that may be the way forward to fix the "gc losing objects" in > multi worktrees. I've given it lots of thoughts in the last 24 hours. > Still can't find any fundamental flaw... I see that you posted a separate message outlining the idea yesterday and I didn't see any response (and I was sick and lacked energy to think it through); I think the basic approach to use "an API to bring set of refs hidden from your normal view" is sensible. Except for the unfortunate naming of the interface that makes it sound as if it is only to access submodules, but that is where the feature original came from, so let's not complain too loudly ;-) > Nguyễn Thái Ngọc Duy (2): > refs.c: add resolve_ref_submodule() > worktree.c: use submodule interface to access refs from another worktree > > branch.c | 3 +- > refs.c | 20 +++++++++---- > refs.h | 3 ++ > worktree.c | 99 > +++++++++++++++----------------------------------------------- > worktree.h | 2 +- > 5 files changed, 44 insertions(+), 83 deletions(-)
