On Thu, Jan 24, 2019 at 10:26:18AM -0800, Junio C Hamano wrote: > Nickolai Belakovski <nbelakovski@xxxxxxxxx> writes: > > > Yes, the parser used the atom argument in an earlier version of this > > patch, but we since moved the map out of the atom since it only needs > > to exist once globally. Even though we have a caching mechanism for > > atoms it still seemed like a logical move to explicitly keep one > > instance of the map globally. > > I think that is a mistaken move from an earlier version to this > one. The worktree-related stuff only becomes necessary and belongs > to the %(worktreepath) atom, so unless there is a compelling reason > not to, we should hang it there, instead of introducing a global. > When you have --format='%(worktreepath) %(worktreepath)', you'd have > only one shared instance of it in used_atom[] to ensure that we have > a singleton instance. What if you have other atoms that need worktrees? E.g., does %(worktreepath:foo) use the same used_atom slot? What if we have another worktree-related atom? If anything, I'd suggest going in the opposite direction, and teaching the worktree code a function for looking up a working tree by ref. And then it can handle its own cache to implement that reverse-mapping efficiently. > The object_info support in the file, which is relatively new, may be > what you borrowed the wrong idea of preferring globals from; I think > it should be taken as an anti-pattern. And that one is a good example where we _do_ need the global, because we already have multiple atoms pulling from it. I think the right level is "global to the ref-filter context", but we do not have that concept yet (hence why used_atoms, etc, are all file-static globals). -Peff
