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

Re: [PATCH 0/3] revision: refactor ref_excludes to ref_visibility

From
Taylor Blau <me@ttaylorr.com>
Date
Jun 22, 2023, 12:49 UTC
Message-ID
<ZJRDZ7NhyNpTV8jD@nand.local>
In-Reply-To
<ZJRBsDq8NI9EInel@nand.local>
On Thu, Jun 22, 2023 at 08:42:24AM -0400, Taylor Blau wrote:
Show 19 quoted lines
> On Wed, Jun 21, 2023 at 07:35:09PM +0000, John Cai via GitGitGadget wrote:
> > The ref_excludes API is used to tell which refs should be excluded. However,
> > there are times when we would want to add refs to explicitly include as
> > well. 4fe42f326e (pack-refs: teach pack-refs --include option, 2023-05-12)
> > taught pack-refs how to include certain refs, but did it in a more manual
> > way by keeping the ref patterns in a separate string list. Instead, we can
> > easily extend the ref_excludes API to include refs as well, since this use
> > case fits into the API nicely.
>
> After reading this description, I am not sure why you can't "include" a
> reference that would otherwise be excluded by passing the rules:
>
>   - refs/heads/exclude/*
>   - !refs/heads/exclude/but/include/me
>
> (where the '!' prefix in the last rule is what brings back the included
> reference).
>
> But let's read on and see if there is something that I'm missing.

Having read this series in detail, I am puzzled. I don't think that there is any limitation of the existing reference hiding rules that wouldn't permit what you're trying to do by adding the list of references you want to include at the end of the exclude list, so long as they are each prefixed with the magic "!" sentinel.

I think splitting the list of excluded references into individual excluded and non-excluded references creates some awkwardness. For one: excluded references already can cause us to include a reference, so splitting that behavior across two lists seems difficult to reason about.

For example, if your excluded list contains:
  - refs/heads/foo
  - refs/heads/bar
  - !refs/heads/foo/baz
and your included lists contains:
  - refs/heads/bar/baz/quux

I am left wondering: why doesn't the rule pertaining to refs/heads/foo/baz show up in the included list? Likewise, what happens with refs/heads/bar/baz/quux? It is a child of an excluded rule, so the question is which list takes priority.

Mostly, I am wondering if I am missing something that would explain why you couldn't modify the above example's excluded list to contain something like "!refs/heads/bar/baz/quux", eliminating the need for the include list entirely.

Thanks, Taylor

Previous: Taylor BlauNext: Taylor Blau
Message 9 of 13 in “revision: refactor ref_excludes to ref_visibility”
  1. 0/3 revision: refactor ref_excludes to ref_visibilityJohn Cai via GitGitGadget, Jun 21, 2023
  2. 2/3 revision: add ref_visible() helperJohn Cai via GitGitGadget, Jun 21, 2023
  3. 1/3 revision: rename ref_excludes to ref_visibilityJohn Cai via GitGitGadget, Jun 21, 2023
  4. Taylor BlauJun 22, 2023
  5. 3/3 pack-refs: use new ref_visible() helperJohn Cai via GitGitGadget, Jun 21, 2023
  6. Junio C HamanoJun 21, 2023
  7. Taylor BlauJun 22, 2023
  8. Taylor BlauJun 22, 2023
  9. Taylor BlauJun 22, 2023
  10. Taylor BlauJun 22, 2023
  11. Taylor BlauJun 22, 2023
  12. John CaiJun 23, 2023
  13. Junio C HamanoJun 23, 2023

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.