summaryrefslogtreecommitdiff
path: root/t/t1303-wacky-config.sh
AgeCommit message (Collapse)AuthorFilesLines
2018-10-07t/*: fix ordering of expected/observed argumentsLibravatar Matthew DeVore1-2/+2
Fix various places where the ordering was obviously wrong, meaning it was easy to find with grep. Signed-off-by: Matthew DeVore <matvore@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-08-18make config --add behave correctly for empty and NULL valuesLibravatar Tanay Abhra1-0/+20
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>
2013-12-06config: arbitrary number of matches for --unset and --replace-allLibravatar Thomas Rast1-0/+64
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>
2011-04-11config: support values longer than 1023 bytesLibravatar Erik Faye-Lund1-1/+1
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>
2009-04-17Fix buffer overflow in config parserLibravatar Thomas Jarosch1-1/+8
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>
2008-09-03tests: use "git xyzzy" form (t0000 - t3599)Libravatar Nanako Shiraishi1-1/+1
Converts tests between t0050-t3903. Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-24tests: do not use implicit "git diff --no-index"Libravatar Junio C Hamano1-1/+1
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>
2008-05-05config.c: Escape backslashes in section names properlyLibravatar Bryan Donlan1-0/+6
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>
2008-01-02config: handle lack of newline at end of file betterLibravatar Jeff King1-0/+37
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>