From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: What's cooking in git.git (Feb 2016, #05; Wed, 17)
Date: Wed, 17 Feb 2016 18:25:56 -0500 [thread overview]
Message-ID: <20160217232556.GA26077@sigill.intra.peff.net> (raw)
In-Reply-To: <xmqqio1nge5b.fsf@gitster.mtv.corp.google.com>
On Wed, Feb 17, 2016 at 02:34:08PM -0800, Junio C Hamano wrote:
> * 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'.
Please hold off a bit; I have a re-roll coming for this one.
> * 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?
I think what we ended up with (and what you have queued here) is an
improvement.
I had some question about the tip one, which is a kind-of follow-on, and
makes the error message you get in certain cases a bit less
non-specific. You were "on the fence...but slightly inclined to take"
it.
Even if we drop it, I think the first two patches are an improvement.
-Peff
[1] http://article.gmane.org/gmane.comp.version-control.git/285935
next prev parent reply other threads:[~2016-02-17 23:26 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-17 22:34 What's cooking in git.git (Feb 2016, #05; Wed, 17) Junio C Hamano
2016-02-17 23:25 ` Jeff King [this message]
2016-02-18 17:51 ` Junio C Hamano
2016-02-22 22:12 ` whither merge-tree? (was: What's cooking in git.git (Feb 2016, #05; Wed, 17)) Jeff King
2016-02-22 22:45 ` whither merge-tree? Junio C Hamano
2016-02-23 5:02 ` Jeff King
2016-02-23 5:14 ` Jeff King
2016-02-23 6:03 ` Jeff King
2016-02-23 6:04 ` [PATCH 1/3] merge-one-file: use empty blob for add/add base Jeff King
2016-02-23 6:06 ` [PATCH 2/3] merge-tree: drop generate_common strategy Jeff King
2016-02-23 6:07 ` [PATCH 3/3] xdiff: drop XDL_EMIT_COMMON Jeff King
2016-02-23 6:35 ` whither merge-tree? Junio C Hamano
2016-02-23 7:18 ` Jeff King
2016-02-23 9:49 ` Stefan Frühwirth
2016-02-24 7:28 ` Dennis Kaarsemaker
2016-02-24 7:57 ` Jeff King
2016-02-24 7:58 ` Jeff King
2016-02-23 12:36 ` Johannes Schindelin
2016-02-23 12:41 ` Duy Nguyen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160217232556.GA26077@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).