Re: What's cooking in git.git (Sep 2019, #02; Wed, 18)
- From
Taylor Blau <me@ttaylorr.com>
- Date
- Sep 20, 2019, 17:08 UTC
- Message-ID
- <20190920170811.GA62895@syl.local>
- In-Reply-To
- <xmqqy2yl44lw.fsf@gitster-ct.c.googlers.com>
On Wed, Sep 18, 2019 at 03:33:15PM -0700, Junio C Hamano wrote:
Show 9 quoted lines
> * tb/commit-graph-harden (2019-09-09) 3 commits > - commit-graph.c: handle corrupt/missing trees > - commit-graph.c: handle commit parsing errors > - t/t5318: introduce failing 'git commit-graph write' tests > > The code to parse and use the commit-graph file has been made more > robust against corrupted input. > > Will merge to 'next'.
Thanks for moving my topic along. This was found while generating commit-graph files on all repositories hosted on GitHub, and some corrupt repositories triggered the behavior.
We've been running this patch since a few days before I submitted it to the mailing list without issue, and it certainly does squash the issue I originally found.
Show 9 quoted lines
> * jk/disable-commit-graph-during-upload-pack (2019-09-12) 2 commits > - upload-pack: disable commit graph more gently for shallow traversal > - commit-graph: bump DIE_ON_LOAD check to actual load-time > > The "upload-pack" (the counterpart of "git fetch") needs to disable > commit-graph when responding to a shallow clone/fetch request, but > the way this was done made Git panic, which has been corrected. > > Will merge to 'next'.
This one has a similar origin story, and has also been running at GitHub for a few weeks. Happily, it does as it advertises and makes the commit-graph process faster.
Show 11 quoted lines
> * jk/partial-clone-sparse-blob (2019-09-16) 4 commits > - list-objects-filter: use empty string instead of NULL for sparse "base" > - list-objects-filter: give a more specific error sparse parsing error > - list-objects-filter: delay parsing of sparse oid > - t5616: test cloning/fetching with sparse:oid=<oid> filter > > The name of the blob object that stores the filter specification > for sparse cloning/fetching was interpreted in a wrong place in the > code, causing Git to abort. > > Will merge to 'next'.
A previous version of this series is running at GitHub, too, and also without issue.
Thanks, Taylor