Re: What's cooking in git.git (Aug 2013, #06; Tue, 27)

Jeff King [off-list ref] writes:

On Tue, Aug 27, 2013 at 12:22:30PM -0700, Junio C Hamano wrote:

quoted

* jk/config-int-range-check (2013-08-21) 2 commits
  (merged to 'next' on 2013-08-22 at 465efb3)
 + teach git-config to output large integers
 + config: properly range-check integer values

 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.

 Will cook in 'next'.

I think Jonathan had some concerns about the test in the first one, and
there was an open question in the second of whether we wanted to add
something like --ulong, call it something more agnostic like
--file-size, or simply teach --int to use 64-bit integers everywhere for
simplicity.

Thoughts?

Are the scripts that use "git config --<type>" expected to know the
representation type used by C binaries on the platform?  If so,
letting them say "git config --ulong 3g" when setting a new value,
and "git config --ulong" when asking the current value with range
checking does make sense.  When the underlying code uses "int" (as
opposed to "int32_t") to read the value for a variable on any
platform, then "git config --int 3g" that does not warn only because
it is running on 64-bit platform may not help very much.  The users
can protect themselves by learning to use "config --int32 3g", but I
am not sure that is a sensible approach---rather, "config --int"
that makes sure that the current value or the value being set is
within range on any sensible platform may be a lot more user-friendly.

quoted

* jk/mailmap-incomplete-line (2013-08-25) 2 commits
 - mailmap: avoid allocation when reading from blob
 - mailmap: handle mailmap blobs without trailing newlines

 Will merge to 'next'.

Did you want me to squash these? The second one more or less eradicates
the changes made to the first one. I mainly did them separately in case
we were going to only do the first half on maint.

Hmm, perhaps.  Is reading mailmap from a blob commonly done and
deserves a maint update down for 1.8.3/1.8.2 series?

I'll be rewinding the 'next' soonish (either tomorrow or Thursday),
so I'll try to remember not to merge this (yet).

quoted

* jk/write-broken-index-with-nul-sha1 (2013-08-26) 1 commit
 - write_index: optionally allow broken null sha1s

 Am I waiting for another reroll?

Yep, just sent v3.

Thanks.