Re: What's cooking in git.git (Feb 2016, #05; Wed, 17)

> * jk/tighten-alloc (2016-02-15) 18 commits
>  - ewah: convert to REALLOC_ARRAY, etc
>  - convert ewah/bitmap code to use xmalloc
>  - diff_populate_gitlink: use a strbuf
>  - transport_anonymize_url: use xstrfmt
>  - git-compat-util: drop mempcpy compat code
>  - sequencer: simplify memory allocation of get_message
>  - test-path-utils: fix normalize_path_copy output buffer size
>  - fetch-pack: simplify add_sought_entry
>  - fast-import: simplify allocation in start_packfile
>  - write_untracked_extension: use FLEX_ALLOC helper
>  - use st_add and st_mult for allocation size computation
>  - convert trivial cases to FLEX_ARRAY macros
>  - use xmallocz to avoid size arithmetic
>  - convert trivial cases to ALLOC_ARRAY
>  - add helpers for allocating flex-array structs
>  - harden REALLOC_ARRAY and xcalloc against size_t overflow
>  - tree-diff: catch integer overflow in combine_diff_path allocation
>  - add helpers for detecting size_t overflow
> 
>  Update various codepaths to avoid manually-counted malloc().
> 
>  Will merge to 'next'.

> * nd/dwim-wildcards-as-pathspecs (2016-02-10) 3 commits
>  - get_sha1: don't die() on bogus search strings
>  - check_filename: tighten dwim-wildcard ambiguity
>  - checkout: reorder check_filename conditional
> 
>  "git show 'HEAD:Foo[BAR]Baz'" did not interpret the argument as a
>  rev, i.e. the object named by the the pathname with wildcard
>  characters in a tree object.
> 
>  I lost track of this topic; did we decide that this is a good thing
>  to do, or unnecessary noise to only cater to a crazy use case?