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

Re: [PATCH v4 02/10] ref-filter: make the 'color' use ref_formatting_state

From
Eric Sunshine <sunshine@sunshineco.com>
Date
Jul 26, 2015, 04:28 UTC
Message-ID
<CAPig+cQ3tFFC8MMNfwo0V_hyYi8EoSfaQLei0+S+Tpz=2sMJ8g@mail.gmail.com>
In-Reply-To
<CAOLa=ZT0LALR0gQaRfVnpyhScSKrSLP+QPQioe+uEH+KJYs=Ow@mail.gmail.com>
On Sat, Jul 25, 2015 at 12:15 AM, Karthik Nayak <karthik.188@gmail.com> wrote:
Show 22 quoted lines
> On Sat, Jul 25, 2015 at 3:16 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> Karthik Nayak <karthik.188@gmail.com> writes:
>>> Make color which was considered as an atom, to use
>>> ref_formatting_state and act as a pseudo atom. This allows
>>> interchangeability between 'align' and 'color'.
>>>
>>> Signed-off-by: Karthik Nayak <karthik.188@gmail.com>
>>> ---
>> I think 1/10 and 2/10 are the other way around.  Preferably, these
>> would be three patches, in this order:
>>
>>  (1) prepare the "formatting state" and pass it around; no other
>>      code change.
>>
>>  (2) have "color" use that facility.
>>
>>  (3) add a new feature using that facility.
>>
>> The first two may want to be combined into a single patch, if it
>> does not make the patch too noisy.
>
> Ill reverse the patches and merge the first two as you suggested.

While reviewing patch 1/10, it required more effort and was distracting to have to separate out (mentally) changes which were specific to the new %(align:X) pseudo-atom and those which introduced the "formatting state". As such, it probably would be a good idea to aim for the three distinct patches suggested by Junio rather than aiming, up front, to merge the first two. After all, they are conceptually distinct changes, and keeping them separate is friendlier to reviewers. In the end, you may find that patch 1 is so trivial that it can be merged with patch 2 without making review more difficult, however, keeping them distinct during development helps you avoid conflating unrelated changes.

Previous: Karthik NayakNext: Eric Sunshine
Message 18 of 36 in “port tag.c to use ref-filter APIs”
  1. 0/10 port tag.c to use ref-filter APIsKarthik Nayak, Jul 24, 2015
  2. 01/10 ref-filter: add option to align atoms to the leftKarthik Nayak, Jul 24, 2015
  3. Junio C HamanoJul 24, 2015
  4. Junio C HamanoJul 24, 2015
  5. Karthik NayakJul 25, 2015
  6. Eric SunshineJul 26, 2015
  7. Karthik NayakJul 26, 2015
  8. Eric SunshineJul 26, 2015
  9. Karthik NayakJul 26, 2015
  10. Matthieu MoyJul 27, 2015
  11. Duy NguyenJul 27, 2015
  12. Jacob KellerJul 27, 2015
  13. Duy NguyenJul 27, 2015
  14. Duy NguyenJul 28, 2015
  15. 02/10 ref-filter: make the 'color' use ref_formatting_stateKarthik Nayak, Jul 24, 2015
  16. Junio C HamanoJul 24, 2015
  17. Karthik NayakJul 25, 2015
  18. Eric SunshineJul 26, 2015
  19. Eric SunshineJul 26, 2015
  20. Karthik NayakJul 26, 2015
  21. 03/10 ref-filter: add option to filter only tagsKarthik Nayak, Jul 24, 2015
  22. 04/10 ref-filter: support printing N lines from tag annotationKarthik Nayak, Jul 24, 2015
  23. Eric SunshineJul 26, 2015
  24. Karthik NayakJul 26, 2015
  25. 05/10 ref-filter: add support to sort by versionKarthik Nayak, Jul 24, 2015
  26. Junio C HamanoJul 25, 2015
  27. Karthik NayakJul 26, 2015
  28. Junio C HamanoJul 27, 2015
  29. Karthik NayakJul 27, 2015
  30. 06/10 ref-filter: add option to match literal patternKarthik Nayak, Jul 24, 2015
  31. Eric SunshineJul 26, 2015
  32. Karthik NayakJul 26, 2015
  33. 07/10 tag.c: use 'ref-filter' data structuresKarthik Nayak, Jul 24, 2015
  34. 08/10 tag.c: use 'ref-filter' APIsKarthik Nayak, Jul 24, 2015
  35. 09/10 tag.c: implement '--format' optionKarthik Nayak, Jul 24, 2015
  36. 10/10 tag.c: implement '--merged' and '--no-merged' optionsKarthik Nayak, Jul 24, 2015

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.