kernel/git - git - PowerEL Git System

Author	SHA1	Message	Date
Tanay Abhra	c8466645ed	make config --add behave correctly for empty and NULL values Currently if we have a config file like, [foo] baz bar = and we try something like, "git config --add foo.baz roll", Git will segfault. Moreover, for "git config --add foo.bar roll", it will overwrite the original value instead of appending after the existing empty value. The problem lies with the regexp used for simulating --add in `git_config_set_multivar_in_file()`, "^$", which in ideal case should not match with any string but is true for empty strings. Instead use a regexp like "a^" which can not be true for any string, empty or not. For removing the segfault add a check for NULL values in `matches()` in config.c. Signed-off-by: Tanay Abhra <tanayabh@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	11 years ago
Thomas Rast	83786fa412	config: arbitrary number of matches for --unset and --replace-all git-config used a static match array to hold the matches we want to unset/replace when using --unset or --replace-all. Use a variable-sized array instead. This in particular fixes the symptoms git-svn had when storing large numbers of svn-remote..added-placeholder entries in the config file. While the tests are rather more paranoid than just --unset and --replace-all, the other operations already worked. Indeed git-svn's usage only breaks the first time after* creating so many entries, when it wants to unset and re-add them all. Reported-by: Jess Hottenstein <jess.hottenstein@gmail.com> Signed-off-by: Thomas Rast <tr@thomasrast.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>	11 years ago
Erik Faye-Lund	e96c19c50f	config: support values longer than 1023 bytes parse_value in config.c has a static buffer of 1024 bytes that it parse the value into. This can sometimes be a problem when a config file contains very long values. It's particularly amusing that git-config already is able to write such files, so it should probably be able to read them as well. Fix this by using a strbuf instead of a fixed-size buffer. Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	14 years ago
Thomas Jarosch	e0b3cc0dff	Fix buffer overflow in config parser When interpreting a config value, the config parser reads in 1+ space character(s) and puts -one- space character in the buffer as soon as the first non-space character is encountered (if not inside quotes). Unfortunately the buffer size check lacks the extra space character which gets inserted at the next non-space character, resulting in a crash with a specially crafted config entry. The unit test now uses Java to compile a platform independent .NET framework to output the test string in C# :o) Read: Thanks to Johannes Sixt for the correct printf call which replaces the perl invocation. Signed-off-by: Thomas Jarosch <thomas.jarosch@intra2net.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	16 years ago
Nanako Shiraishi	0cb0e143ff	tests: use "git xyzzy" form (t0000 - t3599) Converts tests between t0050-t3903. Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Junio C Hamano	3af828634f	tests: do not use implicit "git diff --no-index" As a general principle, we should not use "git diff" to validate the results of what git command that is being tested has done. We would not know if we are testing the command in question, or locating a bug in the cute hack of "git diff --no-index". Rather use test_cmp for that purpose. Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Bryan Donlan	e5c349ba11	config.c: Escape backslashes in section names properly If an element of the configuration key name other than the first or last contains a backslash, it is not escaped on output, but is treated as an escape sequence on input. Thus, the backslash is lost when re-loading the configuration. This patch corrects this by having backslashes escaped properly, and introduces a new test for this bug. Signed-off-by: Bryan Donlan <bdonlan@fushizen.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Jeff King	02e5ba4ae6	config: handle lack of newline at end of file better The config parsing routines use the static global 'config_file' to store the FILE* pointing to the current config file being parsed. The function get_next_char() automatically converts an EOF on this file to a newline for the convenience of its callers, and it sets config_file to NULL to indicate that EOF was reached. This throws away useful information, though, since some routines want to call ftell on 'config_file' to find out exactly _where_ the routine ended. In the case of a key ending at EOF boundary, we ended up segfaulting in some cases (changing that key or adding another key in its section), or failing to provide the necessary newline (adding a new section). This patch adds a new flag to indicate EOF and uses that instead of setting config_file to NULL. It also makes sure to add newlines where necessary for truncated input. All three included tests fail without the patch. Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago