On Thu, Mar 17 2022, Teng Long wrote: > Ævar Arnfjörð Bjarmason wrote on Thu, 10 Mar 2022 14:56:56 +0100 > >> I don't think all of these need to be squashed or fixed up into the >> proposed series, but are just various small issues/questions I came >> with while reviewing it. Brief notes >> >> Ævar Arnfjörð Bjarmason (7): >> ... > > > I looked these commits in "RFC/REVIEW" and I think each one is a good > improvement. So next, to make the squashes or keep it alone I think > maybe it's like: > > > (1) ls-tree tests: add tests for --name-status > > They are new test codes that better than old ones. > > Action: Keep it individually. > > (2) ls-tree tests: exhaustively test fast & slow path for --format > > They are better test codes for the correctness formatting mechanism. > > Action: Squash into commit 'ls-tree: introduce "--format" option' > > (3) ls-tree: remove dead labels > > They remove the dead labels, and you mentioned it should be squash into > the commit which brought them in. > > Action: Squash into commit 'ls-tree: slightly refactor `show_tree()`' > > (4) ls-tree: remove unused "MODE_UNSPECIFIED" > > As the subject describes, remove unused "MODE_UNSPECIFIED" and make > "mutx_option" to a better name "mutx_option". It's the prepared commit > for 'ls-tree: remove FIELD_*, just use MODE_*'' > > Action: Squash into commit 'ls-tree: slightly refactor `show_tree()`' > > (5) ls-tree: detect and error on --name-only --name-status > > Optimized the incompatible detecting tests codes in "t/t3103-ls-tree-misc.sh" > and add a new 'MODE_NAME_STATUS'. > > Action: Keep it individually. > > (6) ls-tree: remove FIELD_*, just use MODE_* > > Using MODE directlly and make a format-mode mappings for fast-path detection. > > Action: Keep it individually. > > (7) ls-tree: split up "fast path" callbacks > > Expand "ls_tree_cmdmode_format" structure for each formats with the specific > show function and split up the current show functions name. > > Action: Keep it individually. All sounds good, or rather. I really meant those as "hey maybe it's useful, you decide what to do with it". So I'm happy with whatever you picked here :) > This is the way I try to continue this work, please let me know if I understand you wrong. > > I look forward to your reply and I will decide the next step based on the reply. If we have > a consistent understanding of the next actions, I will try to make a pull request to your > Git fork first. If there is no problem, I will continue to send patches to the mailing list. Hi, thanks for looking at it. I think it's better to just post a re-roll on the list for discussion, with whatever changed you think are appropriate. Thanks!
