Hi, On Thu, 19 Jan 2017, Michael Haggerty wrote: > On 01/19/2017 12:55 PM, Duy Nguyen wrote: > > I've started working on fixing the "git gc" issue with multiple > > worktrees, which brings me back to this. Just some thoughts. Comments > > are really appreciated. > > > > In the current code, files backend has special cases for both > > submodules (explicitly) and linked worktrees (hidden behind git_path). > > There is another terrible hack also needed to implement linked > worktrees, namely that the `refs/bisect/` hierarchy is manually inserted > into the `ref_cache`, because otherwise it wouldn't be noticed when > iterating over loose references via `readdir()`. > > Other similar hacks would be required if other reference subtrees are > declared to be per-worktree. > > > But if a backend has to handle this stuff, all future backends have to > > too. Which does not sound great. Imagine we have "something" in > > addition to worktrees and submodules in future, then all backends have > > to learn about it. > > Agreed, the status quo is not pretty. > > I kindof think that it would have been a better design to store the > references for all linked worktrees in the main repository's ref-store. > For example, the "bisect" refs for a worktree named "<name>" could have > been stored under "refs/worktrees/<name>/bisect/*". That strikes me as a good design, indeed. It addresses very explicitly the root cause of the worktree problems: Git's source code was developed for years with the assumption that there is a 1:1 mapping between ref names and SHA-1s in each repository, and the way worktrees were implemented broke that assumption. So introducing a new refs/ namespace -- that is visible to all other worktrees -- would have addressed that problem. This, BTW, is related to my concerns about introducing a "shadow" config layer for worktrees: I still think it would be a bad idea, and very likely to cause regressions in surprising ways, to allow such config "overlays" per-worktree, as Git's current code's assumption is that there is only one config per repository, and that it can, say, set one config setting to match another (which in the per-worktree case would possibly hold true in only one worktree only). Instead, introducing a new "namespace" in the (single) config similar to refs/worktrees/<name> could address that problem preemptively. Ciao, Johannes