Junio C Hamano <gitster@xxxxxxxxx> writes: > Phillip Wood <phillip.wood123@xxxxxxxxx> writes: > >> Thanks I'd missed that discussion. I see that at the end of that >> discussion Junio was concerned that the proposed "" did not account >> for "refs/worktrees/$worktree/*" [1] - how has that been resolved? > > Ah, that is an excellent point. > ... > The use of dashed-options to include hierachies that are by default > excluded (e.g. "--include-root-refs" and "--include-worktree-refs") > feels limiting, but should be sufficient for our needs, both current > (i.e. I want to see HEAD and FETCH_HEAD) and in the immediate future > (i.e. I want to see worktree refs from that worktree), and I can buy > that as a good alternative solution, at least in the shorter term. > > I still worry that it may make introducing the negative ref patterns > harder, though. How does --include-worktree-refs=another to include > the worktree refs from another worktree in refs/worktrees/another > interact with a negative pattern that was given from the command > line that overlaps with it? Whatever interaction rules we define, > can we easily explain it in the documentation? > > Just like "an empty string tells Git to include everything" is a > perfectly reasonable approach if we plan to never allow > refs/worktrees/ hierarchy, "dashed-options for selected hierarchies" > is a perfectly reasonable approach if we plan to never allow > negative limit patterns, I suspect. We should stop complexity at > some point, and the decision to never support negative limit > patterns might be the place to draw that line. I dunno. For now, let's block the kn/for-all-refs topic until we figure out the UI issue. Which means this (and the reftable integration that started to depend on it) will not be in the upcoming release. FWIW, I am leaning towards "a set of narrowly targetted command line options (like "--include-root-refs")" approach over "a empty string defeats the built-in default of 'refs/' limit". Thanks.
