Re: What's cooking in git.git (Aug 2019, #01; Thu, 1)

Jeff King [off-list ref] writes:

On Thu, Aug 01, 2019 at 01:05:12PM -0700, Junio C Hamano wrote:

quoted

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

quoted

* jk/tree-walk-overflow (2019-07-31) 6 commits

...

quoted

 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@gmail.com/

if it's not too late / too much trouble to fix.

Thanks, both.  I think I caught it before yesterday's integration
run.

quoted

* 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.