- 26 5月, 2017 2 次提交
-
-
由 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>
-
- 17 5月, 2017 1 次提交
-
-
由 Ævar Arnfjörð Bjarmason 提交于
Change the conditional inclusion mechanism to support e.g. gitdir:~/git_tree/repo where ~/git_tree is a symlink to /mnt/stuff/repo. This worked in the initial version of this facility[1], but regressed later in the series while solving a related bug[2]. Now gitdir: will match against the symlinked path (e.g. gitdir:~/git_tree/repo) in addition to the current /mnt/stuff/repo path. Since this is already in a release version note in the documentation that this behavior changed, so users who expect their configuration to work on both v2.13.0 and some future version of git with this fix aren't utterly confused. 1. commit 3efd0bed ("config: add conditional include", 2017-03-01) 2. commit 86f95157 ("config: resolve symlinks in conditional include's patterns", 2017-04-05) Signed-off-by: NÆvar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 08 5月, 2017 1 次提交
-
-
由 Johannes Schindelin 提交于
In case of errors, we really want the file descriptor to be closed. Discovered by a Coverity scan. Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 27 4月, 2017 1 次提交
-
-
由 Johannes Schindelin 提交于
Git's source code assumes that unsigned long is at least as precise as time_t. Which is incorrect, and causes a lot of problems, in particular where unsigned long is only 32-bit (notably on Windows, even in 64-bit versions). So let's just use a more appropriate data type instead. In preparation for this, we introduce the new `timestamp_t` data type. By necessity, this is a very, very large patch, as it has to replace all timestamps' data type in one go. As we will use a data type that is not necessarily identical to `time_t`, we need to be very careful to use `time_t` whenever we interact with the system functions, and `timestamp_t` everywhere else. Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 20 4月, 2017 1 次提交
-
-
由 Nguyễn Thái Ngọc Duy 提交于
Config file reading order is important because each file can override values in the previous files and this is expected behavior. Normally we read in this order, all in do_git_config_sequence(): 1. $HOME/.gitconfig 2. $GIT_DIR/config 3. config from command line However in read_early_config() the order may be swapped a bit if setup_git_directory() has not been called: 1. $HOME/.gitconfig 2. $GIT_DIR/config is NOT read because .git dir is not found _yet_ 3. config from command line 4. $GIT_DIR/config is now READ (after discover_git_directory() call) The reading at step 4 could override config at step 3, which is not the expectation. Now that we could pass the .git dir around, we could feed discover_git_directory() back to step 2, so that it works again, and remove step 4. Noticed-by: NJeff King <peff@peff.net> Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 18 4月, 2017 2 次提交
-
-
由 Nguyễn Thái Ngọc Duy 提交于
If setup_git_directory() and friends have not been called, get_git_dir() (because of includeIf.gitdir:XXX) would lead to die("BUG: setup_git_env called without repository"); There are two cases when a config file could be read before $GIT_DIR is located. The first one is check_repository_format(), where we read just the one file $GIT_DIR/config to check if we could understand this repository. This case should be safe. We do not parse include directives, which can only be triggered from git_config_with_options, but setup code uses a lower-level function. The concerned variables should never be hidden away behind includes anyway. The second one is triggered in check_pager_config() when we're about to run an external git command. We might be able to find $GIT_DIR in this case, which is exactly what read_early_config() does (and also is what check_pager_config() uses). Conditional includes and get_git_dir() could be triggered by the first git_config_with_options() call there, before discover_git_directory() is used as a fallback $GIT_DIR detection. Detect this special "early reading" case, pass down the $GIT_DIR, either from previous setup or detected by discover_git_directory(), and make conditional include use it. Noticed-by: NBert Wesarg <bert.wesarg@googlemail.com> 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 提交于
So far we can only pass one flag, respect_includes, to thie function. We need to pass some more (non-flag even), so let's make it accept a struct instead of an integer. Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 15 4月, 2017 2 次提交
-
-
由 Nguyễn Thái Ngọc Duy 提交于
$GIT_DIR returned by get_git_dir() is normalized, with all symlinks resolved (see setup_work_tree function). In order to match paths (or patterns) against $GIT_DIR char-by-char, they have to be normalized too. There is a note in config.txt about this, that the user need to resolve symlinks by themselves if needed. The problem is, we allow certain path expansion, '~/' and './', for convenience and can't ask the user to resolve symlinks in these expansions. Make sure the expanded paths have all symlinks resolved. PS. The strbuf_realpath(&text, get_git_dir(), 1) is still needed because get_git_dir() may return relative path. Noticed-by: NTorsten Bögershausen <tboegi@web.de> 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 the next patch we need the ability to expand '~' to real_path($HOME). But we can't do that from outside because '~' is part of a pattern, not a true path. Add an option to expand_user_path() to do so. Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 14 4月, 2017 1 次提交
-
-
由 David Turner 提交于
Unfortunately, in order to push some large repos where a server does not support chunked encoding, the http postbuffer must sometimes exceed two gigabytes. On a 64-bit system, this is OK: we just malloc a larger buffer. This means that we need to use CURLOPT_POSTFIELDSIZE_LARGE to set the buffer size. Signed-off-by: NDavid Turner <dturner@twosigma.com> Reviewed-by: NJonathan Nieder <jrnieder@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 15 3月, 2017 3 次提交
-
-
由 Johannes Schindelin 提交于
Earlier, we punted and simply assumed that we are in the top-level directory of the project, and that there is no .git file but a .git/ directory so that we can read directly from .git/config. However, that is not necessarily true. We may be in a subdirectory. Or .git may be a gitfile. Or the environment variable GIT_DIR may be set. To remedy this situation, we just refactored the way setup_git_directory() discovers the .git/ directory, to make it reusable, and more importantly, to leave all global variables and the current working directory alone. Let's discover the .git/ directory correctly in read_early_config() by using that new function. This fixes 4 known breakages in t7006. Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Johannes Schindelin 提交于
So far, we only look whether the startup_info claims to have seen a git_dir. However, do_git_config_sequence() (and consequently the git_config_with_options() call used by read_early_config() asks the have_git_dir() function whether we have a .git/ directory, which in turn also looks at git_dir and at the environment variable GIT_DIR. And when this is the case, the repository config is handled already, so we do not have to do that again explicitly. Let's just use the same function, have_git_dir(), to determine whether we have to handle .git/config explicitly. Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Johannes Schindelin 提交于
The pager configuration needs to be read early, possibly before discovering any .git/ directory. Let's not hide this function in pager.c, but make it available to other callers. Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 12 3月, 2017 1 次提交
-
-
由 Nguyễn Thái Ngọc Duy 提交于
Sometimes a set of repositories want to share configuration settings among themselves that are distinct from other such sets of repositories. A user may work on two projects, each of which have multiple repositories, and use one user.email for one project while using another for the other. Setting $GIT_DIR/.config works, but if the penalty of forgetting to update $GIT_DIR/.config is high (especially when you end up cloning often), it may not be the best way to go. Having the settings in ~/.gitconfig, which would work for just one set of repositories, would not well in such a situation. Having separate ${HOME}s may add more problems than it solves. Extend the include.path mechanism that lets a config file include another config file, so that the inclusion can be done only when some conditions hold. Then ~/.gitconfig can say "include config-project-A only when working on project-A" for each project A the user works on. In this patch, the only supported grouping is based on $GIT_DIR (in absolute path), so you would need to group repositories by directory, or something like that to take advantage of it. We already have include.path for unconditional includes. This patch goes with includeIf.<condition>.path to make it clearer that a condition is required. The new config has the same backward compatibility approach as include.path: older git versions that don't understand includeIf will simply ignore them. Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 02 3月, 2017 4 次提交
-
-
由 Christian Couder 提交于
This function will be used in a following commit to get the expiration time of the shared index files from the config, and it is generic enough to be put in "config.c". Signed-off-by: NChristian Couder <chriscool@tuxfamily.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Christian Couder 提交于
This new function will be used in a following commit to get the value of the "splitIndex.maxPercentChange" config variable. Signed-off-by: NChristian Couder <chriscool@tuxfamily.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Christian Couder 提交于
This new function will be used in a following commit to know if we want to use the split index feature or not. Signed-off-by: NChristian Couder <chriscool@tuxfamily.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Christian Couder 提交于
Signed-off-by: NChristian Couder <chriscool@tuxfamily.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 25 2月, 2017 2 次提交
-
-
由 Jeff King 提交于
The parse_config_key() function was introduced to make it easier to match "section.subsection.key" variables. It also handles the simpler "section.key", and the caller is responsible for distinguishing the two from its out-parameters. Most callers who _only_ want "section.key" would just use a strcmp(var, "section.key"), since there is no parsing required. However, they may still use parse_config_key() if their "section" variable isn't a constant (an example of this is in parse_hide_refs_config). Using the parse_config_key is a bit clunky, though: const char *subsection; int subsection_len; const char *key; if (!parse_config_key(var, section, &subsection, &subsection_len, &key) && !subsection) { /* matched! */ } Instead, let's treat a NULL subsection as an indication that the caller does not expect one. That lets us write: const char *key; if (!parse_config_key(var, section, NULL, NULL, &key)) { /* matched! */ } Existing callers should be unaffected, as passing a NULL subsection would currently segfault. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jeff King 提交于
This saves us having to repeatedly add in "section_len" (and also avoids walking over the first part of the string multiple times for a strlen() and strrchr()). Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 24 2月, 2017 2 次提交
-
-
由 Junio C Hamano 提交于
The parsing of one-shot assignments of configuration variables that come from the command line historically was quite loose and allowed anything to pass. It also downcased everything in the variable name, even a three-level <section>.<subsection>.<variable> name in which the <subsection> part must be treated in a case sensitive manner. Existing git_config_parse_key() helper is used to parse the variable name that comes from the command line, i.e. "git config VAR VAL", and handles these details correctly. Replace the strbuf_tolower() call in git_config_parse_parameter() with a call to it to correct both issues. git_config_parse_key() does a bit more things that are not necessary for the purpose of this codepath (e.g. it allocates a separate buffer to return the canonicalized variable name because it takes a "const char *" input), but we are not in a performance-critical codepath here. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
git_config_parse_key() implements the validation and downcasing of <section> and <variable> in "<section>[.<subsection>].<variable>" configuration variable name. Move it (and helpers it uses) a bit up so that it can be used by git_config_parse_parameter(), which is used to check configuration settings that are given on the command line (i.e. "git -c VAR=VAL cmd"), in a later patch. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 01 2月, 2017 1 次提交
-
-
由 Cornelius Weig 提交于
When core.logallrefupdates is true, we only create a new reflog for refs that are under certain well-known hierarchies. The reason is that we know that some hierarchies (like refs/tags) are not meant to change, and that unknown hierarchies might not want reflogs at all (e.g., a hypothetical refs/foo might be meant to change often and drop old history immediately). However, sometimes it is useful to override this decision and simply log for all refs, because the safety and audit trail is more important than the performance implications of keeping the log around. This patch introduces a new "always" mode for the core.logallrefupdates option which will log updates to everything under refs/, regardless where in the hierarchy it is (we still will not log things like ORIG_HEAD and FETCH_HEAD, which are known to be transient). Based-on-patch-by: NJeff King <peff@peff.net> Signed-off-by: NCornelius Weig <cornelius.weig@tngtech.com> Reviewed-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 23 12月, 2016 3 次提交
-
-
由 Junio C Hamano 提交于
We somehow forgot to update the "default is 7" in the documentation. Also give a way to explicitly ask the auto-scaling by setting config.abbrev to "auto". Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Nguyễn Thái Ngọc Duy 提交于
We could rely on atexit() to clean up everything, but let's be explicit when we can. And it's good anyway because the function is called the second time in the same process, we're in trouble. This function should not affect the successful case because after commit_lock_file() is called, rollback_lock_file() becomes no-op, as long as it is initialized. Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Brandon Williams 提交于
teach submodules to load a '.gitmodules' file from a commit sha1. This enables the population of the submodule_cache to be based on the state of the '.gitmodules' file from a particular commit. Signed-off-by: NBrandon Williams <bmwill@google.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 21 12月, 2016 2 次提交
-
-
由 Nguyễn Thái Ngọc Duy 提交于
There are two ways to unlock a file: commit, or revert. Rename it to commit_and_out to avoid confusion. 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 提交于
Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 16 11月, 2016 1 次提交
-
-
由 Junio C Hamano 提交于
There are three codepaths that use a variable whose name is pack_compression_level to affect how objects and deltas sent to a packfile is compressed. Unlike zlib_compression_level that controls the loose object compression, however, this variable was static to each of these codepaths. Two of them read the pack.compression configuration variable, using core.compression as the default, and one of them also allowed overriding it from the command line. The other codepath in bulk-checkin did not pay any attention to the configuration. Unify the configuration parsing to git_default_config(), where we implement the parsing of core.loosecompression and core.compression and make the former override the latter, by moving code to parse pack.compression and also allow core.compression to give default to this variable. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 28 9月, 2016 1 次提交
-
-
由 Jeff King 提交于
When we find ambiguous short sha1s, we may get a disambiguation rule from our caller's context. But if we don't, we fall back to treating all sha1s the same, even though most projects will tend to refer only to commits by their short sha1s. This patch introduces a configuration option that lets the user pick a different fallback (e.g., only commits). It's possible that we may want to make this the default, but it's a good idea to start as a config option for two reasons: 1. It lets people experiment with this and see if it's a good idea (i.e., the "tend to" above is an assumption; we don't really know if this will break some obscure cases). 2. Even if we do flip the default, it gives people an escape hatch if it causes problems (you can sometimes override it by asking for "1234^{tree}", but not all combinations are possible). Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 14 9月, 2016 2 次提交
-
-
由 Jeff King 提交于
When git_config() runs, it looks in the system, user-wide, and repo-level config files. It gets the latter by calling git_pathdup(), which in turn calls get_git_dir(). If we haven't set up the git repository yet, this may simply return ".git", and we will look at ".git/config". This seems like it would be helpful (presumably we haven't set up the repository yet, so it tries to find it), but it turns out to be a bad idea for a few reasons: - it's not sufficient, and therefore hides bugs in a confusing way. Config will be respected if commands are run from the top-level of the working tree, but not from a subdirectory. - it's not always true that we haven't set up the repository _yet_; we may not want to do it at all. For instance, if you run "git init /some/path" from inside another repository, it should not load config from the existing repository. - there might be a path ".git/config", but it is not the actual repository we would find via setup_git_directory(). This may happen, e.g., if you are storing a git repository inside another git repository, but have munged one of the files in such a way that the inner repository is not valid (e.g., by removing HEAD). We have at least two bugs of the second type in git-init, introduced by ae5f6776 (lazily load core.sharedrepository, 2016-03-11). It causes init to use git_configset(), which loads all of the config, including values from the current repo (if any). This shows up in two ways: 1. If we happen to be in an existing repository directory, we'll read and respect core.sharedrepository from it, even though it should have no bearing on the new repository. A new test in t1301 covers this. 2. Similarly, if we're in an existing repo that sets core.logallrefupdates, that will cause init to fail to set it in a newly created repository (because it thinks that the user's templates already did so). A new test in t0001 covers this. We also need to adjust an existing test in t1302, which gives another example of why this patch is an improvement. That test creates an embedded repository with a bogus core.repositoryformatversion of "99". It wants to make sure that we actually stop at the bogus repo rather than continuing upward to find the outer repo. So it checks that "git config core.repositoryformatversion" returns 99. But that only works because we blindly read ".git/config", even though we _know_ we're in a repository whose vintage we do not understand. After this patch, we avoid reading config from the unknown vintage repository at all, which is a safer choice. But we need to tweak the test, since core.repositoryformatversion will not return 99; it will claim that it could not find the variable at all. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jeff King 提交于
In git_pager(), we really only care about getting the value of core.pager. But to do so, we use the git_default_config() callback, which loads many other values. Ordinarily it isn't a big deal to load this config an extra time, as it simply overwrites the values from the previous run. But it's a bad idea here, for two reasons: 1. The pager setup may be called very early in the program, before we have found the git repository. As a result, we may fail to read the correct repo-level config file. This is a problem for core.pager, too, but we should at least try to minimize the pollution to other configured values. 2. Because we call setup_pager() from git.c, basically every builtin command _may_ end up reading this config and getting an implicit git_default_config() setup. Which doesn't sound like a terrible thing, except that we don't do it consistently; it triggers only when stdout is a tty. So if a command forgets to load the default config itself (but depends on it anyway), it may appear to work, and then mysteriously fail when the pager is not in use. We can improve this by loading _just_ the core.pager config from git_pager(). Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 24 8月, 2016 1 次提交
-
-
由 Jean-Noel Avila 提交于
Signed-off-by: NJean-Noel Avila <jn.avila@free.fr> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 29 7月, 2016 1 次提交
-
-
由 Vasco Almeida 提交于
Introduced in 473166b9 ("config: add 'origin_type' to config_source struct", 2016-02-19), Git can inform the user about the origin of a config error, but the implementation does not allow translators to translate the keywords 'file', 'blob, 'standard input', and 'submodule-blob'. Moreover, for the second message, a reason for the error is appended to the message, not allowing translators to translate that reason either. Unfold the message into several templates for each known origin_type. That would result in better translation at the expense of code verbosity. Add enum config_oringin_type to ease management of the various configuration origin types (blob, file, etc). Previously origin type was considered from command line if cf->origin_type == NULL, i.e., uninitialized. Now we set origin_type to CONFIG_ORIGIN_CMDLINE in git_config_from_parameters() and configset_add_value(). For error message in git_parse_source(), use xstrfmt() function to prepare the message string, instead of doing something like it's done for die_bad_number(), because intelligibility and code conciseness are improved for that instance. Signed-off-by: NVasco Almeida <vascomalmeida@sapo.pt> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 11 6月, 2016 1 次提交
-
-
由 Peter Colberg 提交于
Signed-off-by: NPeter Colberg <peter@colberg.org> 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>
-
- 25 5月, 2016 2 次提交
-
-
由 Jeff King 提交于
When we parse a config file, we set up the global "cf" variable as a pointer to a "struct config_source" describing the file we are parsing. This is used for error messages, as well as for lookup functions like current_config_name(). The "cf" variable is NULL in two cases: 1. When we are parsing command-line config, in which case there is no source file. 2. When we are not parsing any config at all. Callers like current_config_name() must assume we are in case 1 if they see a NULL "cf". However, this means that if they are accidentally used outside of a config parsing callback, they will quietly return a bogus answer. This might seem like an unlikely accident (why would you ask for the current config file if you are not parsing config?), but it's actually an easy mistake to make due to the configset caching. git_config() serves the answers from a configset cache, and any calls to current_config_name() will claim that we are parsing command-line config, no matter what the original source. So let's distinguish these cases by having the command-line config parser set up a config_source with a NULL name (which callers already handle properly). We can use this to catch programming errors in some cases, and to give better messages to the user in others. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jeff King 提交于
We have several exits from the function, each of which has to do some cleanup. Let's consolidate these in an "out" label we can jump to. This doesn't save us much now, but it will help as we add more things that need cleanup. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-