On Sat, Apr 09, 2016 at 01:39:05PM -0400, Jeff King wrote: > On Sat, Apr 09, 2016 at 09:02:38AM +0200, Tom G. Christensen wrote: > > > I've finished testing 2.8.1 and I found one more case where a null is being > > printed and causing a segfault. This happens even on Solaris 8 and 9. > > The failling test is t3200.63. > > Oh good, this one wasn't me. :) > > It's just a normal "oops, we feed NULL and nobody on glibc noticed > because it silently replaced it with "(null)" case. I did find a few > other oddities while fixing it, though. +cc Patrick, who worked in this > area most recently. > > [1/3]: config: lower-case first word of error strings > [2/3]: git_config_set_multivar_in_file: all non-zero returns are errors > [3/3]: git_config_set_multivar_in_file: handle "unset" errors > > I think we may want some additional improvements. While doing 1/3, I > noticed that many of these error messages could stand to be marked for > translation. As other people are already looking at mass-conversion, > I stopped short of doing it here (and merely contented myself with > throwing a conflict into their patches ;) ). > > The other thing is that 2/3 notices the error return from the > config-setting functions is weird. It's sometimes negative and sometimes > positive. I fixed this caller, but I think it's possible for the > negative values to leak into our exit codes: > > $ touch .git/config > $ git config foo.bar baz > error: could not lock config file .git/config: File exists > $ echo $? > 255 > > I seem to recall some systems having trouble with negative error codes, > so we may want to make that more consistent. > > -Peff Oh, yeah. Those patches look good to me, thanks for cleaning up my error. Patrick
Attachment:
signature.asc
Description: PGP signature