Duy Nguyen <pclouds@xxxxxxxxx> writes: > On Fri, Feb 09, 2018 at 03:13:30PM -0800, Elijah Newren wrote: >> This takes advantage of the fact that "worktrees/$WORKTREE/HEAD" will >> currently resolve as a ref, which may not be true in the future with >> different ref backends. I don't think it locks us in to supporting >> resolving other worktree HEADs with this syntax, as I view the >> user-visible error message as more of a pointer to a pathname that the >> user will need to fix. If the underlying ref storage changes, naturally >> both this code and the hint may need to change to match. > > I'm leaning more about something like this patch below (which does not > even build, just to demonstrate). A couple points: > > - Instead of doing the hacky refs worktrees/foo/HEAD, we get the > correct ref store for each worktree > - We have an API for getting all (non-broken) worktrees. I realize for > fsck, we may even want to examine semi-broken worktrees as well, but > get_worktrees() can take a flag to accomplish that if needed. Very sensible. When I saw that "fsck" thing, the first thing I wondered was "wait, how are we doing prune and repack while making sure objects reachable only from HEAD in other worktrees are not lost? we must already have an API that gives us where the refs of them are stored in". Thanks for a quick response for course correction.
