Subject: Re: What's cooking in git.git (May 2022, #07; Wed, 25)

From: Victoria Dye <[email-masked]>
Date: Thu, 26 May 2022 09:02:27 -0700

Junio C Hamano wrote:
> * js/ci-github-workflow-markup (2022-05-21) 12 commits
>  - ci: call `finalize_test_case_output` a little later
>  - ci(github): mention where the full logs can be found
>  - ci: use `--github-workflow-markup` in the GitHub workflow
>  - ci(github): avoid printing test case preamble twice
>  - ci(github): skip the logs of the successful test cases
>  - ci: optionally mark up output in the GitHub workflow
>  - ci/run-build-and-tests: add some structure to the GitHub workflow output
>  - ci: make it easier to find failed tests' logs in the GitHub workflow
>  - ci/run-build-and-tests: take a more high-level view
>  - test(junit): avoid line feeds in XML attributes
>  - tests: refactor --write-junit-xml code
>  - ci: fix code style
> 
>  Update the GitHub workflow support to make it quicker to get to the
>  failing test.
> 
>  Will merge to 'next'?
>  source: <[email-masked]>
> 

The latest version of this nicely addressed the feedback I originally had,
particularly in improving page loading time. It's still slower than before
this series, but IMO it's manageable (especially taking into account the
improved information accessibility). 

I don't see (or have) any other unaddressed concerns, so I'm in favor of
moving it to 'next'.

> * ds/sparse-sparse-checkout (2022-05-23) 10 commits
>  - sparse-checkout: integrate with sparse index
>  - p2000: add test for 'git sparse-checkout [add|set]'
>  - sparse-index: complete partial expansion
>  - sparse-index: partially expand directories
>  - sparse-checkout: --no-sparse-index needs a full index
>  - cache-tree: implement cache_tree_find_path()
>  - sparse-index: introduce partially-sparse indexes
>  - sparse-index: create expand_index()
>  - t1092: stress test 'git sparse-checkout set'
>  - t1092: refactor 'sparse-index contents' test
> 
>  "sparse-checkout" learns to work well with the sparse-index
>  feature.
> 
>  Will merge to 'next'?
>  source: <[email-masked]>
> 

Likewise here - V2 handled all of my nits, and V3 made some helpful
improvements to variable naming & documentation. There's nothing else I'm
waiting for on this, so I'd be happy to see it merge to 'next'.