aboutsummaryrefslogtreecommitdiff
path: root/config.c
Commit message (Collapse)AuthorAge
* Merge branch 'ow/config-mailmap-pathname'Junio C Hamano2014-06-16
|\ | | | | | | | | | | | | | | mailmap.file configuration names a pathname, hence should honor ~/path and ~user/path as its value. * ow/config-mailmap-pathname: config: respect '~' and '~user' in mailmap.file
| * config: respect '~' and '~user' in mailmap.fileØystein Walle2014-05-27
| | | | | | | | | | | | | | | | | | git_config_string() does not handle '~' and '~user' as part of the value. Using git_config_pathname() fixes this. Signed-off-by: Øystein Walle <oystwa@gmail.com> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'bg/xcalloc-nmemb-then-size'Junio C Hamano2014-06-16
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Like calloc(3), xcalloc() takes nmemb and then size. * bg/xcalloc-nmemb-then-size: transport-helper.c: rearrange xcalloc arguments remote.c: rearrange xcalloc arguments reflog-walk.c: rearrange xcalloc arguments pack-revindex.c: rearrange xcalloc arguments notes.c: rearrange xcalloc arguments imap-send.c: rearrange xcalloc arguments http-push.c: rearrange xcalloc arguments diff.c: rearrange xcalloc arguments config.c: rearrange xcalloc arguments commit.c: rearrange xcalloc arguments builtin/remote.c: rearrange xcalloc arguments builtin/ls-remote.c: rearrange xcalloc arguments
| * | config.c: rearrange xcalloc argumentsBrian Gesiak2014-05-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | xcalloc() takes two arguments: the number of elements and their size. config.c includes several calls to xcalloc() that pass the arguments in reverse order: the size of a struct lock_file*, followed by the number to allocate. Rearrange them so they are in the correct order. Signed-off-by: Brian Gesiak <modocache@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | Merge branch 'jk/strbuf-tolower'Junio C Hamano2014-06-16
|\ \ \ | | | | | | | | | | | | | | | | * jk/strbuf-tolower: strbuf: add strbuf_tolower function
| * | | strbuf: add strbuf_tolower functionJeff King2014-05-23
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a convenience wrapper to call tolower on each character of the string. This makes config's lowercase() function obsolete, though note that because we have a strbuf, we are careful to operate over the whole strbuf, rather than assuming that a NUL is the end-of-string. We could continue to offer a pure-string lowercase, but there would be no callers (in most pure-string cases, we actually duplicate and lowercase the duplicate, for which we have the xstrdup_tolower wrapper). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | Merge branch 'nd/status-auto-comment-char'Junio C Hamano2014-06-06
|\ \ \ | | | | | | | | | | | | | | | | | | | | * nd/status-auto-comment-char: commit: allow core.commentChar=auto for character auto selection config: be strict on core.commentChar
| * | | commit: allow core.commentChar=auto for character auto selectionNguyễn Thái Ngọc Duy2014-05-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When core.commentChar is "auto", the comment char starts with '#' as in default but if it's already in the prepared message, find another char in a small subset. This should stop surprises because git strips some lines unexpectedly. Note that git is not smart enough to recognize '#' as the comment char in custom templates and convert it if the final comment char is different. It thinks '#' lines in custom templates as part of the commit message. So don't use this with custom templates. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | config: be strict on core.commentCharNguyễn Thái Ngọc Duy2014-05-19
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We don't support comment _strings_ (at least not yet). And multi-byte character encoding could also be misinterpreted. The test with two commas is updated because it violates this. It's added with the patch that introduces core.commentChar in eff80a9 (Allow custom "comment char" - 2013-01-16). It's not clear to me _why_ that behavior is wanted. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | Merge branch 'ew/config-protect-mode'Junio C Hamano2014-06-03
|\ \ \ | |/ / |/| | | | | | | | * ew/config-protect-mode: config: preserve config file permissions on edits
| * | config: preserve config file permissions on editsEric Wong2014-05-06
| |/ | | | | | | | | | | | | | | | | | | | | | | Users may already store sensitive data such as imap.pass in .git/config; making the file world-readable when "git config" is called to edit means their password would be compromised on a shared system. [v2: updated for section renames, as noted by Junio] Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * Merge branch 'jk/config-path-include-fix' into maintJunio C Hamano2014-03-18
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | include.path variable (or any variable that expects a path that can use ~username expansion) in the configuration file is not a boolean, but the code failed to check it. * jk/config-path-include-fix: handle_path_include: don't look at NULL value expand_user_path: do not look at NULL path
* | \ Merge branch 'jk/config-die-bad-number-noreturn'Junio C Hamano2014-04-18
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | Squelch a false compiler warning from older gcc. * jk/config-die-bad-number-noreturn: config.c: mark die_bad_number as NORETURN
| * | | config.c: mark die_bad_number as NORETURNJeff King2014-04-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This can help avoid -Wuninitialized false positives in git_config_int and git_config_ulong, as the compiler now knows that we do not return "ret" if we hit the error codepath. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | Merge branch 'ks/config-file-stdin'Junio C Hamano2014-03-14
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "git config" learned to read from the standard input when "-" is given as the value to its "--file" parameter (attempting an operation to update the configuration in the standard input of course is rejected). * ks/config-file-stdin: config: teach "git config --file -" to read from the standard input config: change git_config_with_options() interface builtin/config.c: rename check_blob_write() -> check_write() config: disallow relative include paths from blobs
| * | | | config: teach "git config --file -" to read from the standard inputKirill A. Shutemov2014-02-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The patch extends git config --file interface to allow read config from stdin. Editing stdin or setting value in stdin is an error. Include by absolute path is allowed in stdin config, but not by relative path. Signed-off-by: Kirill A. Shutemov <kirill@shutemov.name> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | | config: change git_config_with_options() interfaceKirill A. Shutemov2014-02-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We're going to have more options for config source. Let's alter git_config_with_options() interface to accept struct with all source options. Signed-off-by: Kirill A. Shutemov <kirill@shutemov.name> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | | config: disallow relative include paths from blobsJeff King2014-02-18
| | |/ / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When we see a relative config include like: [include] path = foo we make it relative to the containing directory of the file that contains the snippet. This makes no sense for config read from a blob, as it is not on the filesystem. Something like "HEAD:some/path" could have a relative path within the tree, but: 1. It would not be part of include.path, which explicitly refers to the filesystem. 2. It would need different parsing rules anyway to determine that it is a tree path. The current code just uses the "name" field, which is wrong. Let's split that into "name" and "path" fields, use the latter for relative includes, and fill in only the former for blobs. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Kirill A. Shutemov <kirill@shutemov.name> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | Merge branch 'jc/core-checkstat-2.0'Junio C Hamano2014-03-07
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | "core.statinfo" configuration variable, which was a never-advertised synonym to "core.checkstat", has been removed.
| * | | | core.statinfo: remove as promised in Git 2.0Junio C Hamano2013-05-06
| | | | | | | | | | | | | | | | | | | | Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | | Merge branch 'jk/config-path-include-fix'Junio C Hamano2014-02-27
|\ \ \ \ \ | |_|/ / / |/| | | / | | |_|/ | |/| | | | | | | | | | | | | | | | | | | | | | include.path variable (or any variable that expects a path that can use ~username expansion) in the configuration file is not a boolean, but the code failed to check it. * jk/config-path-include-fix: handle_path_include: don't look at NULL value expand_user_path: do not look at NULL path
| * | | handle_path_include: don't look at NULL valueJeff King2014-01-28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When we see config like: [include] path the expand_user_path helper notices that the config value is empty, but we then dereference NULL while printing the error message (glibc will helpfully print "(null)" for us here, but we cannot rely on that). $ git -c include.path rev-parse error: Could not expand include path '(null)' fatal: unable to parse command-line config Instead of tweaking our message, let's actually use config_error_nonbool to match other config variables that expect a value: $ git -c include.path rev-parse error: Missing value for 'include.path' fatal: unable to parse command-line config Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | Merge branch 'cc/starts-n-ends-with'Junio C Hamano2013-12-17
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Remove a few duplicate implementations of prefix/suffix comparison functions, and rename them to starts_with and ends_with. * cc/starts-n-ends-with: replace {pre,suf}fixcmp() with {starts,ends}_with() strbuf: introduce starts_with() and ends_with() builtin/remote: remove postfixcmp() and use suffixcmp() instead environment: normalize use of prefixcmp() by removing " != 0"
| * | | | replace {pre,suf}fixcmp() with {starts,ends}_with()Christian Couder2013-12-05
| | |_|/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Leaving only the function definitions and declarations so that any new topic in flight can still make use of the old functions, replace existing uses of the prefixcmp() and suffixcmp() with new API functions. The change can be recreated by mechanically applying this: $ git grep -l -e prefixcmp -e suffixcmp -- \*.c | grep -v strbuf\\.c | xargs perl -pi -e ' s|!prefixcmp\(|starts_with\(|g; s|prefixcmp\(|!starts_with\(|g; s|!suffixcmp\(|ends_with\(|g; s|suffixcmp\(|!ends_with\(|g; ' on the result of preparatory changes in this series. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | Merge branch 'tr/config-multivalue-lift-max'Junio C Hamano2013-12-12
|\ \ \ \ | |/ / / |/| | | | | | | | | | | * tr/config-multivalue-lift-max: config: arbitrary number of matches for --unset and --replace-all
| * | | config: arbitrary number of matches for --unset and --replace-allThomas Rast2013-12-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | Merge branch 'hv/config-from-blob' into maintJunio C Hamano2013-09-05
| |\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Compilation fix on platforms with fgetc() and friends defined as macros. * hv/config-from-blob: config: do not use C function names as struct members
* | | | | config.c: mark file-local function staticRamsay Jones2013-10-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 7192777 refactors git_parse_ulong, which is public, into a more generic function. But since we kept the git_parse_ulong wrapper, only that part needs to be public; nobody outside the file calls the lower-level git_parse_unsigned. Noticed with sparse. ("'git_parse_unsigned' was not declared. Should it be static?") Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Explained-by: Jeff King <peff@peff.net> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
* | | | | Merge branch 'jk/config-int-range-check'Junio C Hamano2013-09-12
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "git config" did not provide a way to set or access numbers larger than a native "int" on the platform; it now provides 64-bit signed integers on all platforms. * jk/config-int-range-check: git-config: always treat --int as 64-bit internally config: make numeric parsing errors more clear config: set errno in numeric git_parse_* functions config: properly range-check integer values config: factor out integer parsing from range checks
| * | | | | git-config: always treat --int as 64-bit internallyJeff King2013-09-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When you run "git config --int", the maximum size of integer you get depends on how git was compiled, and what it considers to be an "int". This is almost useful, because your scripts calling "git config" will behave similarly to git internally. But relying on this is dubious; you have to actually know how git treats each value internally (e.g., int versus unsigned long), which is not documented and is subject to change. And even if you know it is "unsigned long", we do not have a git-config option to match that behavior. Furthermore, you may simply be asking git to store a value on your behalf (e.g., configuration for a hook). In that case, the relevant range check has nothing at all to do with git, but rather with whatever scripting tools you are using (and git has no way of knowing what the appropriate range is there). Not only is the range check useless, but it is actively harmful, as there is no way at all for scripts to look at config variables with large values. For instance, one cannot reliably get the value of pack.packSizeLimit via git-config. On an LP64 system, git happily uses a 64-bit "unsigned long" internally to represent the value, but the script cannot read any value over 2G. Ideally, the "--int" option would simply represent an arbitrarily large integer. For practical purposes, however, a 64-bit integer is large enough, and is much easier to implement (and if somebody overflows it, we will still notice the problem, and not simply return garbage). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | | | config: make numeric parsing errors more clearJeff King2013-09-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If we try to parse an integer config argument and get a number outside of the representable range, we die with the cryptic message: "bad config value for '%s'". We can improve two things: 1. Show the value that produced the error (e.g., bad config value '3g' for 'foo.bar'). 2. Mention the reason the value was rejected (e.g., "invalid unit" versus "out of range"). A few tests need to be updated with the new output, but that should not be representative of real-world breakage, as scripts should not be depending on the exact text of our stderr output, which is subject to i18n anyway. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | | | config: set errno in numeric git_parse_* functionsJeff King2013-09-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When we are parsing an integer or unsigned long, we use the strto*max functions, which properly set errno to ERANGE if we get a large value. However, we also do further range checks after applying our multiplication factor, but do not set ERANGE. This means that a caller cannot tell if an error was caused by ERANGE or if the input was simply not a valid number. This patch teaches git_parse_signed and git_parse_unsigned to set ERANGE for range errors, and EINVAL for other errors, so that the caller can reliably tell these cases apart. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | | | config: properly range-check integer valuesJeff King2013-09-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When we look at a config value as an integer using the git_config_int function, we carefully range-check the value we get and complain if it is out of our range. But the range we compare to is that of a "long", which we then cast to an "int" in the function's return value. This means that on systems where "int" and "long" have different sizes (e.g., LP64 systems), we may pass the range check, but then return nonsense by truncating the value as we cast it to an int. We can solve this by converting git_parse_long into git_parse_int, and range-checking the "int" range. Nobody actually cared that we used a "long" internally, since the result was truncated anyway. And the only other caller of git_parse_long is git_config_maybe_bool, which should be fine to just use int (though we will now forbid out-of-range nonsense like setting "merge.ff" to "10g" to mean "true", which is probably a good thing). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | | | config: factor out integer parsing from range checksJeff King2013-09-09
| |/ / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When we are parsing integers for config, we use an intmax_t (or uintmax_t) internally, and then check against the size of our result type at the end. We can parameterize the maximum representable value, which will let us re-use the parsing code for a variety of range checks. Unfortunately, we cannot combine the signed and unsigned parsing functions easily, as we have to rely on the signed and unsigned C types internally. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | | Merge branch 'hv/config-from-blob'Junio C Hamano2013-08-30
|\ \ \ \ \ | |/ / / / |/| / / / | |/ / / | | | | | | | | | | | | Portability fix. * hv/config-from-blob: config: do not use C function names as struct members
| * | | config: do not use C function names as struct membersJeff King2013-08-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | According to C99, section 7.1.4: Any function declared in a header may be additionally implemented as a function-like macro defined in the header. Therefore calling our struct member function pointer "fgetc" may run afoul of unwanted macro expansion when we call: char c = cf->fgetc(cf); This turned out to be a problem on uclibc, which defines fgetc as a macro and causes compilation failure. The standard suggests fixing this in a few ways: 1. Using extra parentheses to inhibit the function-like macro expansion. E.g., "(cf->fgetc)(cf)". This is undesirable as it's ugly, and each call site needs to remember to use it (and on systems without the macro, forgetting will compile just fine). 2. Using #undef (because a conforming implementation must also be providing fgetc as a function). This is undesirable because presumably the implementation was using the macro for a performance benefit, and we are dropping that optimization. Instead, we can simply use non-colliding names. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | Merge branch 'hv/config-from-blob'Junio C Hamano2013-07-22
|\ \ \ \ | |/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Allow configuration data to be read from in-tree blob objects, which would help working in a bare repository and submodule updates. * hv/config-from-blob: do not die when error in config parsing of buf occurs teach config --blob option to parse config from database config: make parsing stack struct independent from actual data source config: drop cf validity check in get_next_char() config: factor out config file stack management
| * | | do not die when error in config parsing of buf occursHeiko Voigt2013-07-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If a config parsing error in a file occurs we can die and let the user fix the issue. This is different for the buf parsing function since it can be used to parse blobs of .gitmodules files. If a parsing error occurs here we should proceed since otherwise a database containing such an error in a single revision could be rendered unusable. Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | teach config --blob option to parse config from databaseHeiko Voigt2013-07-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This can be used to read configuration values directly from git's database. For example it is useful for reading to be checked out .gitmodules files directly from the database. Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | config: make parsing stack struct independent from actual data sourceHeiko Voigt2013-07-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To simplify adding other sources we extract all functions needed for parsing into a list of callbacks. We implement those callbacks for the current file parsing. A new source can implement its own set of callbacks. Instead of storing the concrete FILE pointer for parsing we store a void pointer. A new source can use this to store its custom data. Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | config: drop cf validity check in get_next_char()Heiko Voigt2013-07-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The global variable cf is set with an initialized value in all codepaths before calling this function. The complete call graph looks like this: git_config_from_file -> do_config_from -> git_parse_file -> get_next_char -> get_value -> get_next_char -> parse_value -> get_next_char -> get_base_var -> get_next_char -> get_extended_base_var -> get_next_char The variable is initialized in do_config_from. Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | config: factor out config file stack managementHeiko Voigt2013-07-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Because a config callback may start parsing a new file, the global context regarding the current config file is stored as a stack. Currently we only need to manage that stack from git_config_from_file. Let's factor it out to allow new sources of config data. Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | Merge branch 'nd/traces'Junio C Hamano2013-06-20
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | * nd/traces: git.txt: document GIT_TRACE_PACKET core: use env variable instead of config var to turn on logging pack access
| * | | | core: use env variable instead of config var to turn on logging pack accessNguyễn Thái Ngọc Duy2013-06-09
| |/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 5f44324 (core: log offset pack data accesses happened - 2011-07-06) provides a way to observe pack access patterns via a config switch. Setting an environment variable looks more obvious than a config var, especially when you just need to _observe_, and more inline with other tracing knobs we have. Document it as it may be useful for remote troubleshooting. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | Merge branch 'jc/core-checkstat'Junio C Hamano2013-06-05
|\ \ \ \ | | |_|/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The configuration variable core.checkstat was advertised in the documentation but the code expected core.statinfo instead. For now, we accept both core.checkstat and core.statinfo, but the latter will be removed in the longer term. * jc/core-checkstat: deprecate core.statinfo at Git 2.0 boundary
| * | | deprecate core.statinfo at Git 2.0 boundaryJunio C Hamano2013-05-06
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | c08e4d5b5cfa (Enable minimal stat checking, 2013-01-22) advertised the configuration variable core.checkstat in the documentation and its log message, but the code expected core.statinfo instead. For now, add core.checkstat, and warn people who have core.statinfo in their configuration file that we will remove it in Git 2.0. Noticed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | config: allow inaccessible configuration under $HOMEJonathan Nieder2013-04-15
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The changes v1.7.12.1~2^2~4 (config: warn on inaccessible files, 2012-08-21) and v1.8.1.1~22^2~2 (config: treat user and xdg config permission problems as errors, 2012-10-13) were intended to prevent important configuration (think "[transfer] fsckobjects") from being ignored when the configuration is unintentionally unreadable (for example with EIO on a flaky filesystem, or with ENOMEM due to a DoS attack). Usually ~/.gitconfig and ~/.config/git are readable by the current user, and if they aren't then it would be easy to fix those permissions, so the damage from adding this check should have been minimal. Unfortunately the access() check often trips when git is being run as a server. A daemon (such as inetd or git-daemon) starts as "root", creates a listening socket, and then drops privileges, meaning that when git commands are invoked they cannot access $HOME and die with fatal: unable to access '/root/.config/git/config': Permission denied Any patch to fix this would have one of three problems: 1. We annoy sysadmins who need to take an extra step to handle HOME when dropping privileges (the current behavior, or any other proposal that they have to opt into). 2. We annoy sysadmins who want to set HOME when dropping privileges, either by making what they want to do impossible, or making them set an extra variable or option to accomplish what used to work (e.g., a patch to git-daemon to set HOME when --user is passed). 3. We loosen the check, so some cases which might be noteworthy are not caught. This patch is of type (3). Treat user and xdg configuration that are inaccessible due to permissions (EACCES) as though no user configuration was provided at all. An alternative method would be to check if $HOME is readable, but that would not help in cases where the user who dropped privileges had a globally readable HOME with only .config or .gitconfig being private. This does not change the behavior when /etc/gitconfig or .git/config is unreadable (since those are more serious configuration errors), nor when ~/.gitconfig or ~/.config/git is unreadable due to problems other than permissions. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Improved-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'jk/config-parsing-cleanup'Junio C Hamano2013-02-04
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Configuration parsing for tar.* configuration variables were broken. Introduce a new config-keyname parser API to make the callers much less error prone. * jk/config-parsing-cleanup: reflog: use parse_config_key in config callback help: use parse_config_key for man config submodule: simplify memory handling in config parsing submodule: use parse_config_key when parsing config userdiff: drop parse_driver function convert some config callbacks to parse_config_key archive-tar: use parse_config_key when parsing config config: add helper function for parsing key names
| * | config: add helper function for parsing key namesJeff King2013-01-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The config callback functions get keys of the general form: section.subsection.key (where the subsection may be contain arbitrary data, or may be missing). For matching keys without subsections, it is simple enough to call "strcmp". Matching keys with subsections is a little more complicated, and each callback does it in an ad-hoc way, usually involving error-prone pointer arithmetic. Let's provide a helper that keeps the pointer arithmetic all in one place. Signed-off-by: Jeff King <peff@peff.net> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | Merge branch 'jc/custom-comment-char'Junio C Hamano2013-02-04
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Allow a configuration variable core.commentchar to customize the character used to comment out the hint lines in the edited text from the default '#'. * jc/custom-comment-char: Allow custom "comment char"
generated by cgit v1.2.1 (git 2.18.0) at 2024-07-01 16:46:54 +0000