git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 2/2] ref-filter: support filtering of operational refs

From
Junio C Hamano <gitster@pobox.com>
Date
Jan 4, 2024, 23:59 UTC
Message-ID
<xmqq1qawr6p4.fsf@gitster.g>
In-Reply-To
<CAOLa=ZStP6F1njTeoQZwN58k+_0r9LT7z-wg2819FWZPq90wQg@mail.gmail.com>
Karthik Nayak <karthik.188@gmail.com> writes:
> Thanks all for the discussion, I'll try to summarize the path forward
> as per my understanding.

It has already been clear for the past 5 years or so since 3a3b9d8c (refs: new ref types to make per-worktree refs visible to all worktrees, 2018-10-21) that we need to treat "worktrees/foo/HEAD", "worktrees/bar/refs/bisect/bad", etc. as something end-users can access via the normal ref mechansim (by a resolve_ref() call that is eventually made from get_sha1() when these are passed to say "git log"); I just did not remember that one but that does not mean we can suddenly change the rules.

So you'd probably need to tweak the end of your bullet point #3, but other than that it is a great summary.

Thanks.
Show 21 quoted lines
> 1. We want to introduce a way to output all refs. This includes refs
> under "refs/", pseudo refs, HEAD, and any other ref like objects under
> $GIT_DIR. The reasoning being that users are allowed currently to create
> refs without any directory restrictions. So with the upcoming reftable
> backend, it becomes important to provide a utility to print all the refs
> held in the reftable. Ideally we want to restrict such ref's from being
> created but for the time being, since thats allowed, we should also
> provide the utility to print such refs.
>
> 2. In the files backend, this would involve iterating through the
> $GIT_DIR and finding all ref-like objects and printing them.
>
> 3. To expose this to the user, we could do something like
>
>    $ git for-each-ref ""
>
> Which is a natural extension of the current syntax, where the empty
> string would imply that we do not filter to the "refs/" directory.
> It is still not clear whether we should support "worktrees".
>
> Any corrections here?
Previous: Karthik NayakNext: Taylor Blau
Message 21 of 27 in “[RFC 0/2] Initial changes to support printing all refs”
  1. Karthik NayakDec 21, 2023
  2. 1/2 refs: introduce the `refs_single_ref` functionKarthik Nayak, Dec 21, 2023
  3. 2/2 ref-filter: support filtering of operational refsKarthik Nayak, Dec 21, 2023
  4. Junio C HamanoDec 21, 2023
  5. Karthik NayakDec 22, 2023
  6. Junio C HamanoDec 26, 2023
  7. Karthik NayakJan 2, 2024
  8. Junio C HamanoJan 2, 2024
  9. Taylor BlauJan 2, 2024
  10. Patrick SteinhardtJan 3, 2024
  11. Karthik NayakJan 3, 2024
  12. Junio C HamanoJan 3, 2024
  13. Patrick SteinhardtJan 3, 2024
  14. Junio C HamanoJan 3, 2024
  15. Patrick SteinhardtJan 3, 2024
  16. Junio C HamanoJan 3, 2024
  17. Patrick SteinhardtJan 3, 2024
  18. Junio C HamanoJan 3, 2024
  19. Patrick SteinhardtJan 3, 2024
  20. Karthik NayakJan 4, 2024
  21. Junio C HamanoJan 4, 2024
  22. Taylor BlauJan 3, 2024
  23. Patrick SteinhardtJan 3, 2024
  24. Taylor BlauJan 3, 2024
  25. Patrick SteinhardtDec 28, 2023
  26. Karthik NayakJan 2, 2024
  27. Taylor BlauJan 2, 2024

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.