Re: What's cooking in git.git (Jul 2020, #02; Thu, 9)

[Taylor Blau <me@ttaylorr.com>]

On Thu, Jul 09, 2020 at 02:40:49PM -0700, Junio C Hamano wrote:
> * tb/fix-persistent-shallow (2020-07-08) 1 commit
>   (merged to 'next' on 2020-07-08 at ef1709f4bb)
>  + commit.c: don't persist substituted parents when unshallowing
>
>  When "fetch.writeCommitGraph" configuration is set in a shallow
>  repository and a fetch moves the shallow boundary, we wrote out
>  broken commit-graph files that do not match the reality, which has
>  been corrected.

Thanks again for fast-tracking this down to -rc0. It had been on my list
to look at, but I was out of the "office" every other week of last
month, and so it kept getting pushed.

I'm glad that will hopefully end up in the release, and sorry again for
the rush.

> * tb/upload-pack-filters (2020-07-06) 4 commits
>  - upload-pack.c: introduce 'uploadpack.filter.tree.maxDepth'
>  - upload-pack.c: pass 'struct list_objects_filter_options *'
>  - upload-pack.c: allow banning certain object filter(s)
>  - list_objects_filter_options: introduce 'list_object_filter_config_name'
>
>  The component to respond to "git fetch" request is made more
>  configurable to selectively allow or reject object filtering
>  specification used for partial cloning.
>
>  Waiting for reviews.
>  cf. <cover.1593720075.git.me@ttaylorr.com>

Yup. I owe Peff a response on the 'uploadpack.filter' vs
'uploadpackfilter' decision, but otherwise I think that this series
should be relatively straightforward (not the least because we've been
running this at GitHub for months).

Another topic on my list is my series to send a reroll of [1], which is
a series to control whether Bloom data is read out of commit-graphs.
We've been using it during our roll-out of Bloom filters, and it has
been quite helpful for debugging.

...which reminds me, I have a backlog of topics that I need to send
upstream, including:

  - a fix for commit-graphs not using Bloom filters if the top-most
    incremental doesn't have them, but others do

  - a new '--max-new-filters' parameter, which allows the caller to
    specify the number of new filters they're willing to generate before
    stopping early (and writing what they have)

Oops. I didn't mean to ramble so much, but it is helpful for me to get a
list written down of things that I have been thinking about / wanting to
send upstream. Patches soon.

[1]: https://lore.kernel.org/git/cover.1593536481.git.me@ttaylorr.com/

Thanks,
Taylor