Patrick Steinhardt <ps@xxxxxx> writes: > The downside of an empty prefix is that you wouldn't be able to filter > refs outside of the "refs/" hierarchy in case we'd use the empty prefix. > A better alternative would be to use "/" as an indicator that you want > to list refs outside of "refs/". That'd allow for more flexible queries: > > - "/" prints all refs and pseudo refs, even those outside of the > "refs/" hierarchy. > > - "/refs" prints your normal refs. > > - "/something/else" prints refs in "$GIT_DIR/something/else". I do not get this at all, sorry. What makes your "/" cover "refs/" but not "something/"? Unless you have some rule that special cases "/" to apply the "hierarchy prefix" matching rule unevenly, that is not possible. So you can easily lose the "/" all of your above patterns share, go back to what I showed, and apply the morally equivalent special case to an empty prefix and you'd be OK. In any case, I do not think supporting anything other than pseudorefs and HEAD outside "refs/" is a good idea to begin with (the "worktrees/$name/" example), and requiring that all normal references live inside "refs/" hierarchy is a good idea, so all of the above is moot, I would say. Thanks.
