Matheus Tavares <matheus.bernardino@xxxxxx> writes: > Daniel Ferreira (1): > dir-iterator: add tests for dir-iterator API > > Matheus Tavares (8): > clone: better handle symlinked files at .git/objects/ > dir-iterator: use warning_errno when possible > dir-iterator: refactor state machine model > dir-iterator: add flags parameter to dir_iterator_begin > clone: copy hidden paths at local clone > clone: extract function from copy_or_link_directory > clone: use dir-iterator to avoid explicit dir traversal > clone: replace strcmp by fspathcmp > > Ævar Arnfjörð Bjarmason (1): > clone: test for our behavior on odd objects/* content > > Makefile | 1 + > builtin/clone.c | 75 +++++---- > dir-iterator.c | 289 +++++++++++++++++++++-------------- > dir-iterator.h | 60 ++++++-- > refs/files-backend.c | 17 ++- > t/helper/test-dir-iterator.c | 58 +++++++ > t/helper/test-tool.c | 1 + > t/helper/test-tool.h | 1 + > t/t0066-dir-iterator.sh | 163 ++++++++++++++++++++ > t/t5604-clone-reference.sh | 133 ++++++++++++++++ > 10 files changed, 635 insertions(+), 163 deletions(-) > create mode 100644 t/helper/test-dir-iterator.c > create mode 100755 t/t0066-dir-iterator.sh A higher level question is what's the benefit of using dir-iterator API in the first place. After subtracting 356 added lines to t/, it still adds 279 lines while removing only 163 lines, so it is not like "we have a perfect dir-iterator API that can be applied as-is but an older code that predates dir-iterator API was still using an old way, so let's make the latter use the former."
