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

Re: [PATCH v1 2/2] log: add option to choose which refs to decorate

From
Rafael Ascensão <rafa.almas@gmail.com>
Date
Nov 10, 2017, 13:38 UTC
Message-ID
<89e7f8e0-8b0d-fde0-5e28-31173213a26e@gmail.com>
In-Reply-To
<xmqqbmkfhrf3.fsf@gitster.mtv.corp.google.com>
On 07/11/17 00:18, Junio C Hamano wrote:
Show 10 quoted lines
> Jacob Keller <jacob.keller@gmail.com> writes:
> 
> I would have to say that the describe's one is wrong if it does not
> match what for_each_glob_ref() does for the log family of commands'
> "--branches=<pattern>" etc.  describe.c::get_name() uses positive
> and negative patterns, just like log-tree.c::add_ref_decoration()
> would with the patch we are discussing, so perhaps the items in
> these lists should get the same "normalize" treatment the patch 1/2
> of this series brings in to make things consistent?
> 

I agree that describe should receive the "normalize" treatment. However, and following the same reasoning, why should describe users adopt the rules imposed by --glob? I could argue they're also used to the way it works now.

That being said, the suggestion I mentioned earlier would allow to keep both current behaviors consistent at the expense of the extra call to refs.c::ref_exists().

+if (!has_glob_specials(pattern) && !ref_exists(normalized_pattern->buf)) {
+        /* Append implied '/' '*' if not present. */
+        strbuf_complete(normalized_pattern, '/');
+        /* No need to check for '*', there is none. */
+        strbuf_addch(normalized_pattern, '*');
+}

But I don't have enough expertise to decide if this consistency is worth the extra call to refs.c::ref_exists() or if there are other side-effects I am not considering.

>> That being said, if we think the extra glob would not cause
>> problems and generally do what people mean... I guess consistent
>> with --glob would be good... But it's definitely not what I'd
>> expect at first glance.

My position is that consistency is good, but the "first glance expectation" is definitely something important we should take into consideration.

Previous: Junio C HamanoNext: Junio C Hamano
Message 21 of 24 in “Add option to git log to choose which refs receive decoration”
  1. 0/2 Add option to git log to choose which refs receive decorationRafael Ascensão, Nov 4, 2017
  2. 1/2 refs: extract function to normalize partial refsRafael Ascensão, Nov 4, 2017
  3. Junio C HamanoNov 4, 2017
  4. Rafael AscensãoNov 4, 2017
  5. Kevin DaudtNov 4, 2017
  6. Michael HaggertyNov 5, 2017
  7. Michael HaggertyNov 5, 2017
  8. Junio C HamanoNov 6, 2017
  9. Rafael AscensãoNov 6, 2017
  10. Michael HaggertyNov 6, 2017
  11. 2/2 log: add option to choose which refs to decorateRafael Ascensão, Nov 4, 2017
  12. Junio C HamanoNov 4, 2017
  13. Rafael AscensãoNov 4, 2017
  14. Junio C HamanoNov 5, 2017
  15. Junio C HamanoNov 5, 2017
  16. Rafael AscensãoNov 6, 2017
  17. Junio C HamanoNov 6, 2017
  18. Michael HaggertyNov 6, 2017
  19. Jacob KellerNov 6, 2017
  20. Junio C HamanoNov 7, 2017
  21. Rafael AscensãoNov 10, 2017
  22. Junio C HamanoNov 10, 2017
  23. log: add option to choose which refs to decorateRafael Ascensão, Nov 21, 2017
  24. Junio C HamanoNov 22, 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.