- 16 6月, 2017 1 次提交
-
-
由 Johannes Schindelin 提交于
We are about to change the way aliases are expanded, to use the early config machinery. This machinery reports errors in a slightly different manner than the cached config machinery. Let's not get hung up by the precise wording of the message mentioning the line number. It is really sufficient to verify that all the relevant information is given to the user. Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de> Reviewed-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 26 5月, 2017 3 次提交
-
-
由 Nguyễn Thái Ngọc Duy 提交于
When fopen() returns NULL, it could be because the given path does not exist, but it could also be some other errors and the caller has to check. Add a wrapper so we don't have to repeat the same error check everywhere. Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Nguyễn Thái Ngọc Duy 提交于
In many places, Git warns about an inaccessible file after a fopen() failed. To discern these cases from other cases where we want to warn about inaccessible files, introduce a new helper specifically to test whether fopen() failed because the current user lacks the permission to open file in question. Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Nguyễn Thái Ngọc Duy 提交于
This variable is added [1] with the assumption that on a sane system, fopen(<dir>, "r") should return NULL. Linux and FreeBSD do not meet this expectation while at least Windows and AIX do. Let's make sure they behave the same way. I only tested one version on Linux (4.7.0 with glibc 2.22) and FreeBSD (11.0) but since GNU/kFreeBSD is fbsd kernel with gnu userspace, I'm pretty sure it shares the same problem. [1] cba22528 (Add compat/fopen.c which returns NULL on attempt to open directory - 2008-02-08) Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 17 12月, 2016 1 次提交
-
-
由 Jeff King 提交于
Many tests want to run a command outside of any git repo; with the nongit() function this is now a one-liner. It saves a few lines, but more importantly, it's immediately obvious what the code is trying to accomplish. This doesn't convert every such case in the test suite; it just covers those that want to do a one-off command. Other cases, such as the ones in t4035, are part of a larger scheme of outside-repo files, and it's less confusing for them to stay consistent with the surrounding tests. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 15 7月, 2016 1 次提交
-
-
由 Johannes Schindelin 提交于
When we tried to fix in 58461bdf (t1308: do not get fooled by symbolic links to the source tree, 2016-06-02) an obscure case where the user cd's into Git's source code via a symbolic link, a regression was introduced that affects all test runs on Windows. The original patch introducing the test case in question was careful to use `$(pwd)` instead of `$PWD`. This was done to account for the fact that Git's test suite uses shell scripting even on Windows, where the shell's Unix-y paths are incompatible with the main Git executable's idea of paths: it only accepts Windows paths. It is an awkward but necessary thing, then, to use `$(pwd)` (which gives us a Windows path) when interacting with the Git executable and `$PWD` (which gives the shell's idea of the current working directory in Unix-y form) for shell scripts, including the test suite itself. Obviously this broke the use case of the Git maintainer when changing the working directory into Git's source code directory via a symlink, i.e. when `$(pwd)` does not agree with `$PWD`. However, we must not fix that use case at the expense of regressing another use case. Let's special-case Windows here, even if it is ugly, for lack of a more elegant solution. Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 18 6月, 2016 1 次提交
-
-
由 Vasco Almeida 提交于
The test functions test_i18ncmp and test_i18ngrep pretend success if run under GETTEXT_POISON. By using those functions to test output which is correctly marked as translatable, enables one to detect if the strings newly marked for translation are from plumbing output. If they are indeed from plumbing, the test would fail, and the string should be unmarked, since it is not seen by users. Thus, it is productive to not have false positives when running the test under GETTEXT_POISON. This commit replaces normal test functions by their i18n aware variants in use-cases know to be correctly marked for translation, suppressing false positives. Signed-off-by: NVasco Almeida <vascomalmeida@sapo.pt> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 03 6月, 2016 1 次提交
-
-
由 Junio C Hamano 提交于
When your $PWD does not match $(/bin/pwd), e.g. you have your copy of the git source tree in one place, point it with a symbolic link, and then "cd" to that symbolic link before running 'make test', one of the tests in t1308 expects that the per-user configuration was reported to have been read from the true path (i.e. relative to the target of such a symbolic link), but the test-config program reports a path relative to $PWD (i.e. the symbolic link). Instead, expect a path relative to $HOME (aka $TRASH_DIRECTORY), as per-user configuration is read from $HOME/.gitconfig and the test framework sets these shell variables up in such a way to avoid this problem. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 28 5月, 2016 2 次提交
-
-
由 Jeff King 提交于
A config callback passed to git_config() doesn't know very much about the context in which it sees a variable. It can ask whether the variable comes from a file, and get the file name. But without analyzing the filename (which is hard to do accurately), it cannot tell whether it is in system-level config, user-level config, or repo-specific config. Generally this doesn't matter; the point of not passing this to the callback is that it should treat the config the same no matter where it comes from. But some programs, like upload-pack, are a special case: we should be able to run them in an untrusted repository, which means we cannot use any "dangerous" config from the repository config file (but it is OK to use it from system or user config). This patch teaches the config code to record the "scope" of each variable, and make it available inside config callbacks, similar to how we give access to the filename. The scope is the starting source for a particular parsing operation, and remains the same even if we include other files (so a .git/config which includes another file will remain CONFIG_SCOPE_REPO, as it would be similarly untrusted). Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jeff King 提交于
When 473166b9 (config: add 'origin_type' to config_source struct, 2016-02-19) added accessor functions for the origin type and name, it taught them only to look at the "cf" struct that is filled in while we are parsing the config. This is sufficient to make it work with git-config, which uses git_config_with_options() under the hood. That function freshly parses the config files and triggers the callback when it parses each key. Most git programs, however, use git_config(). This interface will populate a cache during the actual parse, and then serve values from the cache. Calling current_config_filename() in a callback here will find a NULL cf and produce an error. There are no such callers right now, but let's prepare for adding some by making this work. We already record source information in a struct attached to each value. We just need to make it globally available and then consult it from the accessor functions. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 26 2月, 2016 1 次提交
-
-
由 Johannes Schindelin 提交于
It is a pilot error to call `git config section.key value` outside of any Git worktree. The message error: could not lock config file .git/config: No such file or directory is not very helpful in that situation, though. Let's print a helpful message instead. Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 23 2月, 2016 1 次提交
-
-
由 Lars Schneider 提交于
Use the config origin_type to print more detailed error messages that inform the user about the origin of a config error (file, stdin, blob). Helped-by: NRamsay Jones <ramsay@ramsayjones.plus.com> Signed-off-by: NLars Schneider <larsxschneider@gmail.com> Acked-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 14 10月, 2014 1 次提交
-
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 08 8月, 2014 2 次提交
-
-
由 Tanay Abhra 提交于
Add tests for `git_config_get_string_const()`, check whether it dies printing the line number and the file name if a NULL value is retrieved for the given key. Signed-off-by: NTanay Abhra <tanayabh@gmail.com> Reviewed-by: NMatthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Tanay Abhra 提交于
Semantic errors (for example, for alias.* variables NULL values are not allowed) in configuration files cause a die printing the line number and file name of the offending value. Add a test documenting that such errors cause a die printing the accurate line number and file name. Signed-off-by: NTanay Abhra <tanayabh@gmail.com> Reviewed-by: NMatthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 30 7月, 2014 1 次提交
-
-
由 Tanay Abhra 提交于
Expose the `config_set` C API as a set of simple commands in order to facilitate testing. Add tests for the `config_set` API as well as for `git_config_get_*()` family for the usual config files. Signed-off-by: NMatthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: NTanay Abhra <tanayabh@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-