On Wed, Jan 03, 2024 at 06:38:02AM -0800, Junio C Hamano wrote:
> Karthik Nayak <karthik.188@xxxxxxxxx> writes:
>
> > The confusion was that I thought Junio was referring to using
> >
> > $ git for-each-ref ""
> >
> > to print all refs under $GIT_DIR, while he was actually talking about
> > "$GIT_DIR/refs/" directory.
>
> I do not think you misunderstood me here, though.
>
> When you have your master branch (refs/heads/master), your v1.0 tag
> (refs/tags/v1.0), and the usual pseudorefs, giving "refs" to "git
> for-each-ref" would yield refs/heads/master and refs/tags/v1.0 but
> not HEAD and others, simply because the pattern "refs" in
>
> $ git for-each-ref "refs"
>
> works as a hierarchy prefix match. You give "refs/heads" and you
> get only your master branch but not tags or HEAD in such a
> repository. As a natural extension to that behaviour, an empty
> string as a hierarchy prefix that matches everything would work
> well: you'd get HEAD, refs/heads/master, and refs/tags/v1.0 as an
> empty prefix would cover all of the hiearchies these three refs (and
> pseudorefs if you had ORIG_HEAD and MERGE_HEAD there) live in.
>
> In any case, it is not a very much interesting to define the syntax
> to tell for-each-ref not to limit itself under "refs/". My point
> was that you do not need a special option for that, as shown above.
I think you're just stating that "it's possible, but not necessarily a
good idea" (let me know if I'm misinterpreting, I'm not quite sure
whether I read this correctly). Anyway, let me add my 2c here, even
though it may ultimately be completely moot.
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'm not sure whether it's a better idea than using a flag and I'd assume
that the implementation would be more complex in that case because the
respective backends would need to special-case leading slashes.
So in the end I'm still in the camp that a flag is likely a better idea.
> What is more interesting is what to do with refs that are specific
> to other worktrees, e.g.
>
> $ git rev-parse "worktrees/$name/refs/bisect/bad"
>
> would currently let you peek into (and worse yet, muck with, if you
> really wanted to, with something like "git update-ref") refs that
> should be only visible in another worktree. Should for-each-ref and
> friends learn a way to iterate over them? I have no answer to that
> question.
That's a good question indeed. I could certainly see an argument that
there should be the possibility to list them to get an allcompassing
view of the repository's refs. It's sure going to get more complex like
that though (which is not a good argument not to do this).
Currently, per-worktree refs are implemented as quasi-separate ref
stores (see `get_worktree_ref_store()`), and the reffiles backend will
indeed use completely separate stacks for each worktree. So ultimately
it makes me think that this is higher-level logic that the ref store
backend wouldn't need to be aware of, but that git-for-each-ref(1) or
related commands would need to handle.
So I'm not quite sure whether we should solve all these related problems
at once. If we were to implement these features via a flag then I could
see us using a value-flag with which you can control what exactly should
be included in the listing. So something like:
- `--with-refs=repository` includes all refs of the current
repository.
- `--with-refs=worktrees` includes refs of all worktrees.
I dunno. I feel like I start to overthink this.
Patrick
Attachment:
signature.asc
Description: PGP signature
