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

Re: [PATCH v3 3/5] name-rev: add support to exclude refs by pattern match

From
Jacob Keller <jacob.keller@gmail.com>
Date
Jan 18, 2017, 22:31 UTC
Message-ID
<CA+P7+xo3bS0EfXaVCZbd6NwbBA8vP5HiZNpAh_4v7S_p2jm+Zg@mail.gmail.com>
In-Reply-To
<xmqqy3y82fs8.fsf@gitster.mtv.corp.google.com>
On Wed, Jan 18, 2017 at 1:56 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 22 quoted lines
> Jacob Keller <jacob.keller@gmail.com> writes:
>
>> Yes this makes sense. I'm still looking at whether the alternative
>> implementation suggested based on the git-log style would make more
>> sense or not, but if we keep this as is, the added text you gave is
>> important.
>
> I actually think it is a red-herring that "git log" honors "orders";
> it does, but that is not a result of carefully considering the
> desired behaviour.  It instead is a historical wart that came from
> the fact that "--branches" and friends uses for_each_glob_ref_in()
> that takes the top-level hierarchy paths like "refs/heads/" and the
> implementation of "--exclude" piggybacked into the function in a
> lazy way.
>
> If exclusion were done independently (e.g. in a way similar to what
> you did in this series using subpath match), we wouldn't have had
> the "the user must give exclude patterns first that would affect the
> next inclusion pattern, at which point the exclude patterns are
> cleared and the user needs to start over", which is an end-user
> experience that is clunky.
>

However, it is useful that exclude patterns only apply to specific match parameters? That is the advantage of the other implementation.

I think I agree that it's not really worth the complexity, as it requires a much more complex explanation of how the parameters interact, and in general doesn't provide that much more expressiveness, since at least for "git describe" by definition it either finds the tag as a match or not. Sure you could say "include all tags matching x but only if they don't match y" and include all tags matching z even if they match y" using that mechanism, but I think that makes the entire thing needlessly more complicated than "we use a tag if it matches any match and doesn't match any exclude".

Thanks, Jake

Previous: Junio C HamanoNext: Jacob Keller
Message 9 of 22 in “extend git-describe pattern matching”
  1. 0/5 extend git-describe pattern matchingJacob Keller, Jan 18, 2017
  2. 4/5 describe: teach --match to accept multiple patternsJacob Keller, Jan 18, 2017
  3. 5/5 describe: teach describe negative pattern matchesJacob Keller, Jan 18, 2017
  4. Junio C HamanoJan 18, 2017
  5. 3/5 name-rev: add support to exclude refs by pattern matchJacob Keller, Jan 18, 2017
  6. Junio C HamanoJan 18, 2017
  7. Jacob KellerJan 18, 2017
  8. Junio C HamanoJan 18, 2017
  9. Jacob KellerJan 18, 2017
  10. 2/5 name-rev: extend --refs to accept multiple patternsJacob Keller, Jan 18, 2017
  11. Junio C HamanoJan 18, 2017
  12. Jacob KellerJan 18, 2017
  13. Junio C HamanoJan 18, 2017
  14. 1/5 doc: add documentation for OPT_STRING_LISTJacob Keller, Jan 18, 2017
  15. Junio C HamanoJan 18, 2017
  16. Philip OakleyJan 18, 2017
  17. Junio C HamanoJan 18, 2017
  18. Johannes SchindelinJan 19, 2017
  19. Jacob KellerJan 18, 2017
  20. Junio C HamanoJan 19, 2017
  21. Junio C HamanoJan 18, 2017
  22. Jacob KellerJan 18, 2017

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.