Jeff King <peff@xxxxxxxx> writes: > On Thu, Aug 01, 2019 at 01:05:12PM -0700, Junio C Hamano wrote: > >> [Graduated to "master"] >> [...] >> * jk/repack-silence-auto-bitmap-warning (2019-07-31) 3 commits >> (merged to 'next' on 2019-07-31 at 3aa218347c) >> + repack: simplify handling of auto-bitmaps and .keep files >> + repack: silence warnings when auto-enabled bitmaps cannot be built >> + t7700: clean up .keep file in bitmap-writing test >> >> Squelch unneeded and misleading warnings from "repack" when the >> command attempts to generate pack bitmaps without explicitly asked >> for by the user. > > After your "I need to digest this third one" comment in the thread, I > was surprised to see this merged so soon. :) I think it's fine, and I'd > be happy to see it in the upcoming release, but I just wanted to double > check that it was intentional. Yes, thanks for the simplification. It just took me a while to refresh my memory on the role '--honor-pack-keep' option and ignore_packed_keep_on_disk setting play in builtin/pack-objects.c, which is dense code. >> * jk/tree-walk-overflow (2019-07-31) 6 commits > ... >> Will merge to 'next'. > > Thanks. Stolee noted a minor typo fix in the commit message: > > https://public-inbox.org/git/b99561c9-cd7c-aca0-c7dd-a9916b7bd429@xxxxxxxxx/ > > if it's not too late / too much trouble to fix. Thanks, both. I think I caught it before yesterday's integration run. >> * js/early-config-with-onbranch (2019-07-31) 1 commit >> (merged to 'next' on 2019-08-01 at 26b713c824) >> + config: work around bug with includeif:onbranch and early config >> >> The recently added [includeif "onbranch:branch"] feature does not >> work well with an early config mechanism, as it attempts to find >> out what branch we are on before we even haven't located the git >> repository. The inclusion during early config scan is ignored to >> work around this issue. >> >> Will merge to 'master'. > > I had some open comments here on how the "do we have a repo" check is > done, but I think what is committed here is functionally equivalent. I > can pursue the NULL the_repository cleanups separately. Yeah, I think Dscho's one is good enough for the upcoming release. Thanks.
