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

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. [ref]

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/ (local)

Thanks,
Taylor