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, 21:13 UTC
Message-ID
<CA+P7+xo4-45je995LLoyh-LbGTTf3EZUVW-UV+Dd=Wg0EGRvVA@mail.gmail.com>
In-Reply-To
<xmqqtw8w86xc.fsf@gitster.mtv.corp.google.com>
On Wed, Jan 18, 2017 at 12:11 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 34 quoted lines
> Jacob Keller <jacob.e.keller@intel.com> writes:
>
>> From: Jacob Keller <jacob.keller@gmail.com>
>>
>> Extend name-rev further to support matching refs by adding `--exclude`
>> patterns. These patterns will limit the scope of refs by excluding any
>> ref that matches at least one exclude pattern. Checking the exclude refs
>> shall happen first, before checking the include --refs patterns.
>
> I do not think we should have this "exclude first and then include"
> written down here, as it is an irrelevant implementation detail.
> The desired end result is that only refs that match at least one
> include and none of the exclude survive.  You could implement it by
> first checking with include and then further narrowing that set by
> filtering those that match exclude (I am not saying that "include
> first then exclude" is better---I am saying that it is far less
> important than "at least one include and none of the exclude" to
> mention the order of application).
>
>> +--exclude=<pattern>::
>> +     Do not use any ref whose name matches a given shell pattern. The
>> +     pattern can be one of branch name, tag name or fully qualified ref
>> +     name. If given multiple times, exclude refs that match any of the given
>> +     shell patterns. Use `--no-exclude` to clear the list of exclude
>> +     patterns.
>
> Perhaps insert
>
>     When used together with --refs, only those that match at least
>     one of the --refs patterns and none of the --exclude patterns
>     are used.
>
> before "Use `--no-exclude` to clear"?
>

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.

Thanks, Jake

Previous: Junio C HamanoNext: Junio C Hamano
Message 7 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.