Jeff King <peff@xxxxxxxx> writes: > On Tue, Aug 27, 2013 at 12:22:30PM -0700, Junio C Hamano wrote: > >> * 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. >> * 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). >> * 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html