Re: What's cooking in git.git (Aug 2013, #06; Tue, 27)
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Aug 27, 2013, 21:05 UTC
- Message-ID
- <xmqqbo4ic0ap.fsf@gitster.dls.corp.google.com>
- In-Reply-To
- <20130827205125.GA23783@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
Show 22 quoted lines
> 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.
Show 9 quoted lines
>> * 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).
Show 6 quoted lines
>> * 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.