mbox series

[RFC,0/4] ls-tree: pass state in struct, not globals

Message ID RFC-cover-0.4-00000000000-20221117T134528Z-avarab@gmail.com (mailing list archive)
Headers show
Series ls-tree: pass state in struct, not globals | expand

Message

Ævar Arnfjörð Bjarmason Nov. 17, 2022, 1:48 p.m. UTC 
These are patches I've been carrying locally since April-ish, as a
follow-up to the "ls-tree --format" topic.

I'm submitting them here in reply to Teng's parallel RFC[1].

Teng: This conflicts with your topic, but re my suggestion of
submitting a separate clean-up series in [2] maybe you could look this
over, see how they differ from yours, and see what would make sense to
keep/incorporate for such a clean-up series?

E.g. 1/4 here is the opposite approach of your 3/6[3], but as 3/4
eventually shows we don't need that struct for anything except that
callback case.

1. https://lore.kernel.org/git/20221117113023.65865-1-tenglong.tl@alibaba-inc.com/
2. https://lore.kernel.org/git/221117.86k03tiudl.gmgdl@evledraar.gmail.com/
3. https://lore.kernel.org/git/20221117113023.65865-4-tenglong.tl@alibaba-inc.com/

Ævar Arnfjörð Bjarmason (4):
  ls-tree: don't use "show_tree_data" for "fast" callbacks
  ls-tree: use a "struct options"
  ls-tree: fold "show_tree_data" into "cb" struct
  ls-tree: make "line_termination" less generic

 builtin/ls-tree.c | 255 +++++++++++++++++++++++++++-------------------
 1 file changed, 149 insertions(+), 106 deletions(-)

Comments

Teng Long Nov. 21, 2022, noon UTC | #1 
"Ævar Arnfjörð Bjarmason" <avarab@gmail.com> write:


> These are patches I've been carrying locally since April-ish, as a
> follow-up to the "ls-tree --format" topic.

Cool.

> Teng: This conflicts with your topic, but re my suggestion of
> submitting a separate clean-up series in [2] maybe you could look this
> over, see how they differ from yours, and see what would make sense to
> keep/incorporate for such a clean-up series?

Yes, I'd like to.

> E.g. 1/4 here is the opposite approach of your 3/6[3], but as 3/4
> eventually shows we don't need that struct for anything except that
> callback case.

Ok, I will check it out later.


Thanks.