git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

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