Re: What's cooking in git.git (Sep 2013, #03; Wed, 11)

From: Jeff King <peff@peff.net>
Date: Sep 12, 2013, 05:36 UTC
Message-ID: <20130912053644.GB1977@sigill.intra.peff.net>
In-Reply-To: <xmqqzjrjq6ig.fsf@gitster.dls.corp.google.com>

On Wed, Sep 11, 2013 at 04:32:23PM -0700, Junio C Hamano wrote:

Show 13 quoted lines

> * jk/config-int-range-check (2013-09-09) 5 commits
>   (merged to 'next' on 2013-09-09 at 9ab779d)
>  + git-config: always treat --int as 64-bit internally
>  + config: make numeric parsing errors more clear
>  + config: set errno in numeric git_parse_* functions
>  + config: properly range-check integer values
>  + config: factor out integer parsing from range checks
> 
>  Originally merged to 'next' on 2013-08-22
> 
>  "git config --int section.var 3g" should somehow diagnose that the
>  number does not fit in "int" (on 32-bit platforms anyway) but it
>  did not.

This description is slightly inaccurate since the re-roll. I think it is now:

  "git config" did not provide a way to set or access numbers larger
  than a native "int" on the platform; it now provides 64-bit signed
  integers on all platforms.

Not a big deal, but it may make your life easier if this description ends up in the merge commit, and then you later try to write ReleaseNotes off of it.

It also fixes the mis-detection of 32-bit overflow on certain platforms, but the only likely way to trigger that was via "config --int" (unless you are crazy enough to set gc.auto to 2g or something). But now that git-config is 64-bit that does not even matter, and it is probably not even worth mentioning in the release notes.

-Peff