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

Re: [PATCH 05/15] ref-filter: abstract ref format into its own struct

From
Junio C Hamano <gitster@pobox.com>
Date
Jul 13, 2017, 20:34 UTC
Message-ID
<xmqqlgnsulco.fsf@gitster.mtv.corp.google.com>
In-Reply-To
<CAGZ79kag1B37FBrmDzbRFNVODHp=n1h=xSq_pi1b7Fs4wLoRBg@mail.gmail.com>
Stefan Beller <sbeller@google.com> writes:
Show 14 quoted lines
> On Thu, Jul 13, 2017 at 8:01 AM, Jeff King <peff@peff.net> wrote:
>
>>  builtin/branch.c       | 14 +++++++-------
>>  builtin/for-each-ref.c | 22 ++++++++++++----------
>>  builtin/tag.c          | 30 ++++++++++++++++--------------
>>  builtin/verify-tag.c   | 12 ++++++------
>>  ref-filter.c           | 22 ++++++++++++----------
>>  ref-filter.h           | 22 +++++++++++++++++-----
>>  6 files changed, 70 insertions(+), 52 deletions(-)
>
> The patch looks good to me. So some off-topic comments:
> I reviewed this patch from bottom up, i.e. I started looking at
> ref-filter.h, then  ref-filter.c and then the rest. If only you had formatted
> the patches with an orderfile. ;)

As a reviewer, for this particular patchq, I actually appreciated that ref-filter.[ch] came at the end. That forced me to think.

When I see something that used to be 0 is lost from the parameter list of show_ref_array_item() at a callsite, I was forced to guess what it is by looking at what is moved into the new structure nearby, and keep doing that "figure out what is going on" game until the "author's answer" is revealed at the end of the patch.

By the time I reached ref-filter.[ch], I had a pretty good idea what was done by only looking at the callers and being able to see if my understanding matched the "author's answer" at the end of the patch turned out to be a very good way to double-check if the patch was sane. If I were given the author's answer upfront, especially an answer by somebody as competent as Peff, I'm sure I would have been swayed into believing that whatever is written in the patch must be correct without thinking the changes needed in the patch myself.

I do want to present from Doc to header to code when I am showing my patch to others, so this is probably a good example that illustrates that the preferred presentation order is not just personal preference, but is different on occasion even for the same person.

Previous: Stefan BellerNext: Junio C Hamano
Message 14 of 30 in “making user-format colors conditional on config/tty”
  1. 0/15 making user-format colors conditional on config/ttyJeff King, Jul 13, 2017
  2. 01/15 check return value of verify_ref_format()Jeff King, Jul 13, 2017
  3. 02/15 docs/for-each-ref: update pointer to color syntaxJeff King, Jul 13, 2017
  4. Junio C HamanoJul 13, 2017
  5. 03/15 t: use test_decode_color rather than literal ANSI codesJeff King, Jul 13, 2017
  6. Stefan BellerJul 13, 2017
  7. Jeff KingJul 13, 2017
  8. Junio C HamanoJul 13, 2017
  9. Jeff KingJul 14, 2017
  10. Junio C HamanoJul 13, 2017
  11. 04/15 ref-filter: simplify automatic color resetJeff King, Jul 13, 2017
  12. 05/15 ref-filter: abstract ref format into its own structJeff King, Jul 13, 2017
  13. Stefan BellerJul 13, 2017
  14. Junio C HamanoJul 13, 2017
  15. Junio C HamanoJul 13, 2017
  16. Stefan BellerJul 13, 2017
  17. Junio C HamanoJul 13, 2017
  18. 06/15 ref-filter: move need_color_reset_at_eol into ref_formatJeff King, Jul 13, 2017
  19. Junio C HamanoJul 13, 2017
  20. 07/15 ref-filter: provide a function for parsing sort optionsJeff King, Jul 13, 2017
  21. 08/15 ref-filter: make parse_ref_filter_atom a private functionJeff King, Jul 13, 2017
  22. 09/15 ref-filter: factor out the parsing of sorting atomsJeff King, Jul 13, 2017
  23. 10/15 ref-filter: pass ref_format struct to atom parsersJeff King, Jul 13, 2017
  24. 11/15 color: check color.ui in git_default_config()Jeff King, Jul 13, 2017
  25. 12/15 for-each-ref: load config earlierJeff King, Jul 13, 2017
  26. 13/15 rev-list: pass diffopt->use_colors through to pretty-printJeff King, Jul 13, 2017
  27. 14/15 pretty: respect color settings for %C placeholdersJeff King, Jul 13, 2017
  28. 15/15 ref-filter: consult want_color() before emitting colorsJeff King, Jul 13, 2017
  29. Stefan BellerJul 13, 2017
  30. Junio C HamanoJul 13, 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.