Re: [PATCH v3 0/9] read_tree() and read_tree_recursive() refactoring

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Ævar Arnfjörð Bjarmason  <avarab@xxxxxxxxx> writes:

> A v3 of a refactoring of tree.c. See v2 at
> https://lore.kernel.org/git/20210308022138.28166-1-avarab@xxxxxxxxx/
>
> This brings back pretty much the old read_tree_recursive() under the
> name read_tree_at() as suggested in
> https://lore.kernel.org/git/xmqqft106sok.fsf@gitster.g/
>
> Ævar Arnfjörð Bjarmason (9):
>   ls-files tests: add meaningful --with-tree tests
>   tree.c API: move read_tree() into builtin/ls-files.c
>   ls-files: don't needlessly pass around stage variable
>   ls-files: refactor away read_tree()
>   tree.h API: remove support for starting at prefix != ""
>   tree.h API: remove "stage" parameter from read_tree_recursive()
>   tree.h API: rename read_tree_recursive() to read_tree()
>   show tests: add test for "git show <tree>"
>   tree.h API: expose read_tree_1() as read_tree_at()

The end-result looks good, but it seeps through the structure of the
series that the steps #7-#9 are afterthought of fixing a mistake
made in the step #5.  If #4 refactors away and removes read_tree()
and makes the name available, a natural next step would be to
introduce a thin-wrapper read_tree() around read_tree_recursive(),
which is to be used by majority of callers that do not need
non-empty prefix and stage, and that would become step #5 if I were
doing the series.  That step makes the codebase ready to change the
callers of read_tree_recursive() to call the simpler read_tree(),
which would be step #6.  The read_tree_recursive() would only have
one caller (i.e. the new read_tree() which is a castrated version of
read_tree_recursive()) and renaming it to read_tree_at() would be
another simple step #7.

>  4:  e78d1810b89 =  4:  1c96d5d3611 ls-files: refactor away read_tree()
>  5:  05eecdd7519 !  5:  367cb99224b tree.h API: remove support for starting at prefix != ""
>     @@ Commit message
>          ffd31f661d5 (Reimplement read_tree_recursive() using
>          tree_entry_interesting(), 2011-03-25).
>      
>     -    If in the future we need to support recursively reading trees without
>     -    starting at the root we can easily add a read_tree_recursive_subdir(),
>     -    and make that function a thin wrapper for read_tree_1().
>     +    As it turns out (Murphy's law and all) we're just about to gain a new
>     +    in-tree user that would need this parameter[1]. Let's remove it anyway
>     +    as the common case is going to be to not supply it, A later commit
>     +    will bring back this functionality in different form.
>      
>     -    In the meantime there's no reason to keep around what amounts to dead
>     -    code, just in case we need it in the future.
>     +    1. https://lore.kernel.org/git/xmqqft106sok.fsf@gitster.g/
>      
>          Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx>
>      
>  6:  fcecc82e1c8 =  6:  38e36780e22 tree.h API: remove "stage" parameter from read_tree_recursive()
>  -:  ----------- >  7:  859902ffd83 tree.h API: rename read_tree_recursive() to read_tree()
>  -:  ----------- >  8:  a63c9b49f13 show tests: add test for "git show <tree>"
>  -:  ----------- >  9:  570642c8625 tree.h API: expose read_tree_1() as read_tree_at()




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux