summaryrefslogtreecommitdiff
path: root/t/t1300-repo-config.sh
AgeCommit message (Collapse)AuthorFilesLines
2013-03-29t1300: document some aesthetic failures of the config editorLibravatar Jeff King1-0/+35
The config-editing code used by "git config var value" is built around the regular config callback parser, whose only triggerable item is an actual key. As a result, it does not know anything about section headers, which can result in unnecessarily ugly output: 1. When we delete the last key in a section, we should be able to delete the section header. 2. When we add a key into a section, we should be able to reuse the same section header, even if that section did not have any keys in it already. Unfortunately, fixing these is not trivial with the current code. It would involve the config parser recording and passing back information on each item it finds, including headers, keys, and even comments (or even better, generating an actual in-memory parse-tree). Since these behaviors do not cause any functional problems (i.e., the resulting config parses as expected, it is just uglier than one would like), fixing them can wait until somebody feels like substantially refactoring the parsing code. In the meantime, let's document them as known issues with some tests. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-11-21Merge branch 'jk/config-ignore-duplicates'Libravatar Junio C Hamano1-129/+187
Drop duplicate detection from "git-config --get"; this lets it better match the internal config callbacks, which clears up some corner cases with includes. * jk/config-ignore-duplicates: builtin/config.c: Fix a sparse warning git-config: use git_config_with_options git-config: do not complain about duplicate entries git-config: collect values instead of immediately printing git-config: fix regexp memory leaks on error conditions git-config: remove memory leak of key regexp t1300: test "git config --get-all" more thoroughly t1300: remove redundant test t1300: style updates
2012-11-20Merge branch 'cn/config-missing-path'Libravatar Junio C Hamano1-0/+5
"git config --path $key" segfaulted on "[section] key" (a boolean "true" spelled without "=", not "[section] key = true"). * cn/config-missing-path: config: don't segfault when given --path with a missing value
2012-11-15config: don't segfault when given --path with a missing valueLibravatar Carlos Martín Nieto1-0/+5
When given a variable without a value, such as '[section] var' and asking git-config to treat it as a path, git_config_pathname returns an error and doesn't modify its output parameter. show_config assumes that the call is always successful and sets a variable to indicate that vptr should be freed. In case of an error however, trying to do this will cause the program to be killed, as it's pointing to memory in the stack. Detect the error and return immediately to avoid freeing or accessing the uninitialed memory in the stack. Signed-off-by: Carlos Martín Nieto <cmn@elego.de> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-24git-config: do not complain about duplicate entriesLibravatar Jeff King1-2/+4
If git-config is asked for a single value, it will complain and exit with an error if it finds multiple instances of that value. This is unlike the usual internal config parsing, however, which will generally overwrite previous values, leaving only the final one. For example: [set a multivar] $ git config user.email one@example.com $ git config --add user.email two@example.com [use the internal parser to fetch it] $ git var GIT_AUTHOR_IDENT Your Name <two@example.com> ... [use git-config to fetch it] $ git config user.email one@example.com error: More than one value for the key user.email: two@example.com This overwriting behavior is critical for the regular parser, which starts with the lowest-priority file (e.g., /etc/gitconfig) and proceeds to the highest-priority file ($GIT_DIR/config). Overwriting yields the highest priority value at the end. Git-config solves this problem by implementing its own parsing. It goes from highest to lowest priorty, but does not proceed to the next file if it has seen a value. So in practice, this distinction never mattered much, because it only triggered for values in the same file. And there was not much point in doing that; the real value is in overwriting values from lower-priority files. However, this changed with the implementation of config include files. Now we might see an include overriding a value from the parent file, which is a sensible thing to do, but git-config will flag as a duplication. This patch drops the duplicate detection for git-config and switches to a pure-overwrite model (for the single case; --get-all can still be used if callers want to do something more fancy). As is shown by the modifications to the test suite, this is a user-visible change in behavior. An alternative would be to just change the include case, but this is much cleaner for a few reasons: 1. If you change the include case, then to what? If you just stop parsing includes after getting a value, then you will get a _different_ answer than the regular config parser (you'll get the first value instead of the last value). So you'd want to implement overwrite semantics anyway. 2. Even though it is a change in behavior for git-config, it is bringing us in line with what the internal parsers already do. 3. The file-order reimplementation is the only thing keeping us from sharing more code with the internal config parser, which will help keep differences to a minimum. Going under the assumption that the primary purpose of git-config is to behave identically to how git's internal parsing works, this change can be seen as a bug-fix. Signed-off-by: Jeff King <peff@peff.net>
2012-10-24t1300: test "git config --get-all" more thoroughlyLibravatar Jeff King1-2/+7
We check that we can "--get-all" a multi-valued variable, but we do not actually confirm that the output is sensible. Doing so reveals that it works fine, but this will help us ensure we do not have regressions in the next few patches, which will touch this area. Signed-off-by: Jeff King <peff@peff.net>
2012-10-24t1300: remove redundant testLibravatar Jeff King1-4/+0
This test checks that git-config fails for an ambiguous "get", but we check the exact same thing 3 tests beforehand. Signed-off-by: Jeff King <peff@peff.net>
2012-10-24t1300: style updatesLibravatar Jeff King1-123/+178
The t1300 test script is quite old, and does not use our modern techniques or styles. This patch updates it in the following ways: 1. Use test_cmp instead of cmp (to make failures easier to debug). 2. Use test_cmp instead of 'test $(command) = expected'. This makes failures much easier to debug, and also makes sure that $(command) exits appropriately. 3. Use test_must_fail (easier to read, and checks more rigorously for signal death). 4. Write tests with the usual style of: test_expect_success 'test name' ' test commands && ... ' rather than one-liners, or using backslash-continuation. This is purely a style fixup. There are still a few command happening outside of test_expect invocations, but they are all innoccuous system commands like "cat" and "cp". In an ideal world, each test would be self sufficient and all commands would happen inside test_expect, but it is not immediately obvious how the grouping should work (some of the commands impact the subsequent tests, and some of them are setting up and modifying state that many tests depend on). This patch just picks the low-hanging style fruit, and we can do more fixes on top later. Signed-off-by: Jeff King <peff@peff.net>
2012-08-27Fix tests under GETTEXT_POISON on parseoptLibravatar Jiang Xin1-1/+1
Use the i18n-specific test functions in test scripts for parseopt tests. This issue was was introduced in v1.7.10.1-488-g54e6d: 54e6d i18n: parseopt: lookup help and argument translations when showing usage and been broken under GETTEXT_POISON=YesPlease since. Signed-off-by: Jiang Xin <worldhello.net@gmail.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-25config: reject bogus section names for --rename-sectionLibravatar Jeff King1-0/+8
You can feed junk to "git config --rename-section", which will result in a config file that git will not even parse (so you cannot fix it with git-config). We already have syntactic sanity checks when setting a variable; let's do the same for section names. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-13Merge branch 'ms/maint-config-error-at-eol-linecount'Libravatar Junio C Hamano1-0/+31
When "git config" diagnoses an error in a configuration file and shows the line number for the offending line, it miscounted if the error was at the end of line. By Martin Stenberg * ms/maint-config-error-at-eol-linecount: config: report errors at the EOL with correct line number Conflicts: t/t1300-repo-config.sh
2012-03-12config: report errors at the EOL with correct line numberLibravatar Martin Stenberg1-0/+31
A section in a config file with a missing "]" reports the next line as bad, same goes to a value with a missing end quote. This happens because the error is not detected until the end of the line, when line number is already increased. Fix this by decreasing line number by one for these cases. Signed-off-by: Martin Stenberg <martin@gnutiken.se> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-17config: stop using config_exclusive_filenameLibravatar Jeff King1-0/+25
The git-config command sometimes operates on the default set of config files (either reading from all, or writing to repo config), and sometimes operates on a specific file. In the latter case, we set the magic global config_exclusive_filename, and the code in config.c does the right thing. Instead, let's have git-config use the "advanced" variants of config.c's functions which let it specify an individual filename (or NULL for the default). This makes the code a lot more obvious, and fixes two small bugs: 1. A relative path specified by GIT_CONFIG=foo will look in the wrong directory if we have to chdir as part of repository setup. We already handle this properly for "git config -f foo", but the GIT_CONFIG lookup used config_exclusive_filename directly. By dropping to a single magic variable, the GIT_CONFIG case now just works. 2. Calling "git config -f foo --edit" would not respect core.editor. This is because just before editing, we called git_config, which would respect the config_exclusive_filename setting, even though this particular git_config call was not about looking in the user's specified file, but rather about loading actual git config, just as any other git program would. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-17t1300: add missing &&-chainingLibravatar Jeff King1-1/+1
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-08test: fix '&&' chainingLibravatar Ramkumar Ramachandra1-1/+1
Breaks in a test assertion's && chain can potentially hide failures from earlier commands in the chain by adding " &&" at the end of line to the commands that need them. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Acked-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-21Merge branch 'mm/maint-config-explicit-bool-display' into maintLibravatar Junio C Hamano1-0/+6
* mm/maint-config-explicit-bool-display: config: display key_delim for config --bool --get-regexp
2011-10-19Merge branch 'jk/config-test-cleanup'Libravatar Junio C Hamano1-12/+7
* jk/config-test-cleanup: t1300: attempting to remove a non-existent .git/config is not an error
2011-10-19t1300: attempting to remove a non-existent .git/config is not an errorLibravatar Johannes Sixt1-12/+7
Since some tests before test number 79 ("quoting") are skipped, .git/config does not exist and 'rm .git/config' fails. Fix this particular case. While at it, move other instance of 'rm .git/config' that occur in this file inside the test function to document that the test cases want to protect themselves from remnants of earlier tests. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-17Merge branch 'jk/config-test-cleanup'Libravatar Junio C Hamano1-83/+120
* jk/config-test-cleanup: t1300: test mixed-case variable retrieval t1300: put git invocations inside test function
2011-10-17Merge branch 'mm/maint-config-explicit-bool-display'Libravatar Junio C Hamano1-0/+6
* mm/maint-config-explicit-bool-display: config: display key_delim for config --bool --get-regexp
2011-10-12t1300: test mixed-case variable retrievalLibravatar Jeff King1-0/+27
We should be able to ask for a config value both by its canonical all-lowercase name (as git does internally), as well as by random mixed-case (which will be canonicalized by git-config for us). Subsections are a tricky point, though. Since we have both [section "Foo"] and [section.Foo] you might want git-config to canonicalize the subsection or not, depending on which you are expecting. But there's no way to communicate this; git-config sees only the key, and doesn't know which type of section name will be in the config file. So it must leave the subsection intact, and it is up to the caller to provide a canonical version of the subsection if they want to match the latter form. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-12t1300: put git invocations inside test functionLibravatar Jeff King1-83/+93
This is a very old script, and did a lot of: echo whatever >expect git config foo bar test_expect_success 'cmp .git/config expect' which meant that we didn't actually check that the call to git-config succeeded. Fix this, and while we're at it, modernize the style to use test_cmp. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-10config: display key_delim for config --bool --get-regexpLibravatar Matthieu Moy1-0/+6
The previous logic in show_config was to print the delimiter when the value was set, but Boolean variables have an implicit value "true" when they appear with no value in the config file. As a result, we got: git_Config --get-regexp '.*\.Boolean' #1. Ok: example.boolean git_Config --bool --get-regexp '.*\.Boolean' #2. NO: example.booleantrue Fix this by defering the display of the separator until after the value to display has been computed. Reported-by: Brian Foster <brian.foster@maxim-ic.com> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-06-22config: avoid segfault when parsing command-line configLibravatar Jeff King1-0/+4
We already check for an empty key on the left side of an equals, but we would segfault if there was no content at all. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-06-22config: die on error in command-line configLibravatar Jeff King1-0/+8
The error handling for git_config is somewhat confusing. We collect errors from running git_config_from_file on the various config files and carefully pass them back up. But the two odd things are: 1. We actually die on most errors in git_config_from_file. In fact, the only error we actually pass back up is if fopen() fails on the file. 2. Most callers of git_config do not check the error return at all, but will continue if git_config reports an error. When the code for "git -c core.foo=bar" was added, it dutifully passed errors up the call stack, only for them to be eventually ignored. This makes it inconsistent with the file-parsing code, which will die when it sees malformed config. And it's somewhat unsafe, because it means an error in parsing a typo like: git -c clean.requireforce=ture clean will continue the command, ignoring the config the user tried to give. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-06-22fix "git -c" parsing of values with equals signsLibravatar Jeff King1-0/+6
If you do something like: git -c core.foo="value with = in it" ... we would split your option on "=" into three fields and throw away the third one. With this patch we correctly take everything after the first "=" as the value (keys cannot have an equals sign in them, so the parsing is unambiguous). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-06-01Merge branch 'jk/maint-config-alias-fix' into maintLibravatar Junio C Hamano1-0/+7
* jk/maint-config-alias-fix: handle_options(): do not miscount how many arguments were used config: always parse GIT_CONFIG_PARAMETERS during git_config git_config: don't peek at global config_parameters config: make environment parsing routines static
2011-05-24handle_options(): do not miscount how many arguments were usedLibravatar Junio C Hamano1-1/+1
The handle_options() function advances the base of the argument array and returns the number of arguments it used. The caller in handle_alias() wants to reallocate the argv array it passes to this function, and attempts to do so by subtracting the returned value to compensate for the change handle_options() makes to the new_argv. But handle_options() did not correctly count when "-c <config=value>" is given, causing a wrong pointer to be passed to realloc(). Fix it by saving the original argv at the beginning of handle_options(), and return the difference between the final value of argv, which will relieve the places that move the array pointer from the additional burden of keeping track of "handled" counter. Noticed-by: Kazuki Tsujimoto Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-24config: always parse GIT_CONFIG_PARAMETERS during git_configLibravatar Jeff King1-0/+7
Previously we parsed GIT_CONFIG_PARAMETERS lazily into a linked list, and then checked that list during future invocations of git_config. However, that ignores the fact that the environment variable could change during our run (e.g., because we parse more "-c" as part of an alias). Instead, let's just re-parse the environment variable each time. It's generally not very big, and it's no more work than parsing the config files, anyway. As a bonus, we can ditch all of the linked list storage code entirely, making the code much simpler. The test unfortunately still does not pass because of an unrelated bug in handle_options. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-02-22Disallow empty section and variable namesLibravatar Libor Pechacek1-0/+4
It is possible to break your repository config by creating an invalid key. The config parser in turn chokes on it: $ git init Initialized empty Git repository in /tmp/gittest/.git/ $ git config .foo false $ git config core.bare fatal: bad config file line 6 in .git/config This patch makes git-config reject keys which start or end with a dot and adds tests for these cases. Signed-off-by: Libor Pechacek <lpechacek@suse.cz> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-02-22Sanity-check config variable namesLibravatar Libor Pechacek1-4/+14
Sanity-check config variable names when adding and retrieving them. As a side effect code duplication between git_config_set_multivar and get_value (in builtin/config.c) was removed and the common functionality was placed in git_config_parse_key. This breaks a test in t1300 which used invalid section-less keys in the tests for "git -c". However, allowing such names there was useless, since there was no way to set them via config file, and no part of git actually tried to use section-less keys. This patch updates the test to use more realistic examples as well as adding its own test. Signed-off-by: Libor Pechacek <lpechacek@suse.cz> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-10-21config: treat non-existent config files as emptyLibravatar Jeff King1-0/+29
The git_config() function signals error by returning -1 in two instances: 1. An actual error occurs in opening a config file (parse errors cause an immediate die). 2. Of the three possible config files, none was found. However, this second case is often not an error at all; it simply means that the user has no configuration (they are outside a repo, and they have no ~/.gitconfig file). This can lead to confusing errors, such as when the bash completion calls "git config --list" outside of a repo. If the user has a ~/.gitconfig, the command completes succesfully; if they do not, it complains to stderr. This patch allows callers of git_config to distinguish between the two cases. Error is signaled by -1, and otherwise the return value is the number of files parsed. This means that the traditional "git_config(...) < 0" check for error should work, but callers who want to know whether we parsed any files or not can still do so. [jc: with tests from Jonathan] Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-10-01Skip t1300.70 and 71 on msysGit.Libravatar Pat Thoyts1-3/+3
These two tests fail on msysGit because /dev/null is an alias for nul on Windows and when reading the value back from git config the alias does not match the real filename. Also the HOME environment variable has a unix-style path but git returns a native equivalent path for '~'. As these are platform-dependent equivalent results it seems simplest to skip the test entirely. Moves the NOT_MINGW prereq from t5503 into the test library. Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
2010-07-27Sync with 1.7.1.2Libravatar Junio C Hamano1-1/+23
2010-07-27config --get --path: check for unset $HOMELibravatar Jonathan Nieder1-1/+23
If $HOME is unset (as in some automated build situations), currently git config --path path.home "~" git config --path --get path.home segfaults. Error out with Failed to expand user dir in: '~/' instead. Reported-by: Julien Cristau <jcristau@debian.org> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-28Allow passing of configuration parameters in the command lineLibravatar Alex Riesen1-0/+8
The values passed this way will override whatever is defined in the config files. Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-27Merge branch 'jh/maint-config-file-prefix'Libravatar Junio C Hamano1-0/+11
* jh/maint-config-file-prefix: builtin-config: Fix crash when using "-f <relative path>" from non-root dir
2010-01-26builtin-config: Fix crash when using "-f <relative path>" from non-root dirLibravatar Johan Herland1-0/+11
When your current directory is not at the root of the working tree, and you use the "-f" option with a relative path, the current code tries to read from a wrong file, since argv[2] is now beyond the end of the rearranged argument list. This patch replaces the incorrect argv[2] with the variable holding the given config file name. The bug was introduced by d64ec16 (git config: reorganize to use parseopt). [jc: added test] Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-31builtin-config: add --path option doing ~ and ~user expansion.Libravatar Matthieu Moy1-0/+28
395de250 (Expand ~ and ~user in core.excludesfile, commit.template) introduced a C function git_config_pathname, doing ~/ and ~user/ expansion. This patch makes the feature available to scripts with 'git config --get --path'. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-05Merge branch 'maint-1.6.3' into maintLibravatar Junio C Hamano1-0/+5
* maint-1.6.3: Better usage string for reflog. hg-to-git: don't import the unused popen2 module send-email: remove debug trace config: Keep inner whitespace verbatim
2009-07-31config: Keep inner whitespace verbatimLibravatar Björn Steinbrink1-0/+5
Configuration values are expected to be quoted when they have leading or trailing whitespace, but inner whitespace should be kept verbatim even if the value is not quoted. This is already documented in git-config(1), but the code caused inner whitespace to be collapsed to a single space, breaking, for example, clones from a path that has two consecutive spaces in it, as future fetches would only see a single space. Reported-by: John te Bokkel <tanj.tanj@gmail.com> Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-24After renaming a section, print any trailing variable definitionsLibravatar Alex Vandiver1-0/+22
Signed-off-by: Alex Vandiver <alex@chmrr.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-24Merge branch 'js/windows-tests'Libravatar Junio C Hamano1-1/+1
* js/windows-tests: t0060: fix whitespace in "wc -c" invocation t5503: GIT_DEBUG_SEND_PACK is not supported on MinGW t7004: Use prerequisite tags to skip tests that need gpg Use prerequisites to skip tests that need unzip t3700: Skip a test with backslashes in pathspec Skip tests that require a filesystem that obeys POSIX permissions t0060: Fix tests on Windows Use prerequisite tags to skip tests that depend on symbolic links t9100, t9129: Use prerequisite tags for UTF-8 tests t5302: Use prerequisite tags to skip 64-bit offset tests Skip tests that fail if the executable bit is not handled by the filesystem t3600: Use test prerequisite tags test-lib: Infrastructure to test and check for prerequisites t0050: Check whether git init detected symbolic link support correctly Tests on Windows: $(pwd) must return Windows-style paths test-lib: Work around missing sum on Windows test-lib: Work around incompatible sort and find on Windows Conflicts: t/t3000-ls-files-others.sh
2009-03-22Use prerequisite tags to skip tests that depend on symbolic linksLibravatar Johannes Sixt1-1/+1
Many tests depend on that symbolic links work. This introduces a check that sets the prerequisite tag SYMLINKS if the file system supports symbolic links. Since so many tests have to check for this prerequisite, we do the check in test-lib.sh, so that we don't need to repeat the test in many scripts. To check for 'ln -s' failures, you can use a FAT partition on Linux: $ mkdosfs -C git-on-fat 1000000 $ sudo mount -o loop,uid=j6t,gid=users,shortname=winnt git-on-fat /mnt Clone git to /mnt and $ GIT_SKIP_TESTS='t0001.1[34] t0010 t1301 t403[34] t4129.[47] t5701.7 t7701.3 t9100 t9101.26 t9119 t9124.[67] t9200.10 t9600.6' \ make test (These additionally skipped tests depend on POSIX permissions that FAT on Linux does not provide.) Signed-off-by: Johannes Sixt <j6t@kdbg.org>
2009-03-20Merge branch 'fc/parseopt-config'Libravatar Junio C Hamano1-1/+8
* fc/parseopt-config: config: test for --replace-all with one argument and fix documentation. config: set help text for --bool-or-int git config: don't allow --get-color* and variable type git config: don't allow extra arguments for -e or -l. git config: don't allow multiple variable types git config: don't allow multiple config file locations git config: reorganize to use parseopt git config: reorganize get_color* git config: trivial rename in preparation for parseopt git_config(): not having a per-repo config file is not an error
2009-03-17config: test for --replace-all with one argument and fix documentation.Libravatar Carlos Rica1-1/+8
Option --replace-all only allows at least two arguments, so documentation was needing to be updated accordingly. A test showing that the command fails with only one parameter is also provided. Signed-off-by: Carlos Rica <jasampler@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-07t1300: use test_must_fail as appropriateLibravatar Jeff King1-5/+5
Some of the tests checked the exit code manually, even going so far as to run git outside of the test_expect harness. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-09-24maint: check return of split_cmdline to avoid bad config stringsLibravatar Deskin Miller1-0/+10
As the testcase demonstrates, it's possible for split_cmdline to return -1 and deallocate any memory it's allocated, if the config string is missing an end quote. In both the cases below, which are the only calling sites, the return isn't checked, and using the pointer causes a pretty immediate segfault. Signed-off-by: Deskin Miller <deskinm@umich.edu> Acked-by: Miklos Vajna <vmiklos@frugalware.org> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2008-07-13t/: Use "test_must_fail git" instead of "! git"Libravatar Stephan Beyer1-9/+10
This patch changes every occurrence of "! git" -- with the meaning that a git call has to gracefully fail -- into "test_must_fail git". This is useful to - make sure the test does not fail because of a signal, e.g. SIGSEGV, and - advertise the use of "test_must_fail" for new tests. Signed-off-by: Stephan Beyer <s-beyer@gmx.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-24tests: do not use implicit "git diff --no-index"Libravatar Junio C Hamano1-4/+4
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>