- 16 4月, 2015 1 次提交
-
-
由 Jeff King 提交于
We read config files character-by-character from a stdio handle using fgetc(). This incurs significant locking overhead, even though we know that only one thread can possibly access the handle. We can speed this up by taking the lock ourselves, and then using getc_unlocked to read each character. On a silly pathological case: perl -le ' print "[core]"; print "key$_ = value$_" for (1..1000000) ' >input git config -f input core.key1 this dropped the time to run git-config from: real 0m0.263s user 0m0.260s sys 0m0.000s to: real 0m0.159s user 0m0.152s sys 0m0.004s for a savings of 39%. Most config files are not this big, but the savings should be proportional to the size of the file (i.e., we always save 39%, just of a much smaller number). Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 06 2月, 2015 2 次提交
-
-
由 Jeff King 提交于
Our config code simulates a stdio stream around a buffer, but our fake ungetc() does not behave quite like the real one. In particular, we only rewind the position by one character, but do _not_ actually put the character from the caller into position. It turns out that this does not matter, because we only ever push back the character we just read. In other words, such an assignment would be a noop. But because the function is called ungetc, and because it takes a character parameter, it is a mistake waiting to happen. Actually assigning the character into the buffer would be ideal, but our pointer is actually a "const" copy of the buffer. We do not know who the real owner of the buffer is in this code, and would not want to munge their contents. Instead, we can simply add an assertion that matches what the current caller does, and will let us know if new callers are added that violate the contract. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jeff King 提交于
When we are parsing a config value, if we see a carriage return, we fgetc the next character to see if it is a line feed (in which case we silently drop the CR). If it isn't, we then ungetc the character, and take the literal CR. But we never check whether we in fact got a character at all. If the config file ends in CR, we will get EOF here, and try to ungetc EOF. This works OK for a real stdio stream. The ungetc returns an error, and the next fgetc will then return EOF again. However, our custom buffer-based stream is not so fortunate. It happily rewinds the position of the stream by one character, ignoring the fact that we fed it EOF. The next fgetc call returns the final CR again, over and over, and we end up in an infinite loop. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 14 1月, 2015 1 次提交
-
-
由 Jeff King 提交于
This replaces "x ? xstrdup(x) : NULL" with xstrdup_or_null(x). The change is fairly mechanical, with the exception of resolve_refdup, which can eliminate a temporary variable. There are still a few hits grepping for "?.*xstrdup", but these are of slightly different forms and cannot be converted (e.g., "x ? xstrdup(x->foo) : NULL"). Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 18 12月, 2014 2 次提交
-
-
由 Johannes Schindelin 提交于
The point of disallowing ".git" in the index is that we would never want to accidentally overwrite files in the repository directory. But this means we need to respect the filesystem's idea of when two paths are equal. The prior commit added a helper to make such a comparison for NTFS and FAT32; let's use it in verify_path(). We make this check optional for two reasons: 1. It restricts the set of allowable filenames, which is unnecessary for people who are not on NTFS nor FAT32. In practice this probably doesn't matter, though, as the restricted names are rather obscure and almost certainly would never come up in practice. 2. It has a minor performance penalty for every path we insert into the index. This patch ties the check to the core.protectNTFS config option. Though this is expected to be most useful on Windows, we allow it to be set everywhere, as NTFS may be mounted on other platforms. The variable does default to on for Windows, though. Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jeff King 提交于
The point of disallowing ".git" in the index is that we would never want to accidentally overwrite files in the repository directory. But this means we need to respect the filesystem's idea of when two paths are equal. The prior commit added a helper to make such a comparison for HFS+; let's use it in verify_path. We make this check optional for two reasons: 1. It restricts the set of allowable filenames, which is unnecessary for people who are not on HFS+. In practice this probably doesn't matter, though, as the restricted names are rather obscure and almost certainly would never come up in practice. 2. It has a minor performance penalty for every path we insert into the index. This patch ties the check to the core.protectHFS config option. Though this is expected to be most useful on OS X, we allow it to be set everywhere, as HFS+ may be mounted on other platforms. The variable does default to on for OS X, though. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 18 11月, 2014 1 次提交
-
-
由 René Scharfe 提交于
Using abs() on long values can cause truncation, so use labs() instead. Reported by Clang 3.5 (-Wabsolute-value, enabled by -Wall). Signed-off-by: NRene Scharfe <l.s.r@web.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 02 10月, 2014 3 次提交
-
-
由 Michael Haggerty 提交于
Move the interface declaration for the functions in lockfile.c from cache.h to a new file, lockfile.h. Add #includes where necessary (and remove some redundant includes of cache.h by files that already include builtin.h). Move the documentation of the lock_file state diagram from lockfile.c to the new header file. Signed-off-by: NMichael Haggerty <mhagger@alum.mit.edu> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Michael Haggerty 提交于
For now, we still make sure to allocate at least PATH_MAX characters for the strbuf because resolve_symlink() doesn't know how to expand the space for its return value. (That will be fixed in a moment.) Another alternative would be to just use a strbuf as scratch space in lock_file() but then store a pointer to the naked string in struct lock_file. But lock_file objects are often reused. By reusing the same strbuf, we can avoid having to reallocate the string most times when a lock_file object is reused. Helped-by: NTorsten Bögershausen <tboegi@web.de> Signed-off-by: NMichael Haggerty <mhagger@alum.mit.edu> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Michael Haggerty 提交于
After commit_lock_file() is called, then the lock_file object is necessarily either committed or rolled back. So there is no need to call rollback_lock_file() again in either of these cases. Signed-off-by: NMichael Haggerty <mhagger@alum.mit.edu> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 12 9月, 2014 1 次提交
-
-
由 Jeff King 提交于
Introduce CONFIG_REGEX_NONE as a more explicit sentinel value to say "we do not want to replace any existing entry" and use it in the implementation of "git config --add". Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 03 9月, 2014 1 次提交
-
-
由 René Scharfe 提交于
Instead of using skip_prefix() to check the first part of the string and then strcmp() to check the rest, simply use strcmp() to check the whole string. Signed-off-by: NRene Scharfe <l.s.r@web.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 29 8月, 2014 1 次提交
-
-
由 Steffen Prohaska 提交于
The new function parses an integeral value that fits in unsigned long in human readable form, i.e. possibly with unit suffix, e.g. 10k = 10240, etc., from an environment variable. Parsing of GIT_MMAP_LIMIT and GIT_ALLOC_LIMIT will use it in later patches. Signed-off-by: NSteffen Prohaska <prohaska@zib.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 19 8月, 2014 1 次提交
-
-
由 Tanay Abhra 提交于
Currently if we have a config file like, [foo] baz bar = and we try something like, "git config --add foo.baz roll", Git will segfault. Moreover, for "git config --add foo.bar roll", it will overwrite the original value instead of appending after the existing empty value. The problem lies with the regexp used for simulating --add in `git_config_set_multivar_in_file()`, "^$", which in ideal case should not match with any string but is true for empty strings. Instead use a regexp like "a^" which can not be true for any string, empty or not. For removing the segfault add a check for NULL values in `matches()` in config.c. Signed-off-by: NTanay Abhra <tanayabh@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 08 8月, 2014 6 次提交
-
-
由 Tanay Abhra 提交于
Of all the functions in `git_config*()` family, `git_config()` has the most invocations in the whole code base. Each `git_config()` invocation causes config file rereads which can be avoided using the config-set API. Use the config-set API to rewrite `git_config()` to use the config caching layer to avoid config file rereads on each invocation during a git process lifetime. First invocation constructs the cache, and after that for each successive invocation, `git_config()` feeds values from the config cache instead of rereading the configuration files. 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 提交于
Add `git_die_config` that dies printing the line number and the file name of the highest priority value for the configuration variable `key`. A custom error message is also printed before dying, specified by the caller, which can be skipped if `err` argument is set to NULL. It has usage in non-callback based config value retrieval where we can raise an error and die if there is a semantic error. For example, if (!git_config_get_value(key, &value)){ if (!strcmp(value, "foo")) git_config_die(key, "value: `%s` is illegal", value); else /* do work */ } 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 提交于
Currently `git_config()` returns an integer signifying an error code. During rewrites of the function most of the code was shifted to `git_config_with_options()`. `git_config_with_options()` normally returns positive values if its `config_source` parameter is set as NULL, as most errors are fatal, and non-fatal potential errors are guarded by "if" statements that are entered only when no error is possible. Still a negative value can be returned in case of race condition between `access_or_die()` & `git_config_from_file()`. Also, all callers of `git_config()` ignore the return value except for one case in branch.c. Change `git_config()` return value to void and make it die if it receives a negative value from `git_config_with_options()`. Original-patch-by: NMatthieu Moy <Matthieu.Moy@imag.fr> 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 提交于
Store file name and line number for each key-value pair in the cache during parsing of the configuration files. 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>
-
由 Matthieu Moy 提交于
If a callback returns a negative value to `git_config*()` family, they call `die()` while printing the line number and the file name. Currently the printed line number is off by one, thus printing the wrong line number. Make `linenr` point to the line we just parsed during the call to callback to get accurate line number in error messages. Commit-message-by: NTanay Abhra <tanayabh@gmail.com> Signed-off-by: NTanay Abhra <tanayabh@gmail.com> Signed-off-by: NMatthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Matthieu Moy 提交于
Signed-off-by: NMatthieu Moy <Matthieu.Moy@imag.fr> Reviewed-by: NMatthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 06 8月, 2014 1 次提交
-
-
由 Junio C Hamano 提交于
In a config file, you can do: [foo] bar to turn the "foo.bar" boolean flag on, and you can do: [foo] bar= to set "foo.bar" to the empty string. However, git's "-c" parameter treats both: git -c foo.bar and git -c foo.bar= as the boolean flag, and there is no way to set a variable to the empty string. This patch enables the latter form to do that. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 30 7月, 2014 1 次提交
-
-
由 Tanay Abhra 提交于
Currently `git_config()` uses a callback mechanism and file rereads for config values. Due to this approach, it is not uncommon for the config files to be parsed several times during the run of a git program, with different callbacks picking out different variables useful to themselves. Add a `config_set`, that can be used to construct an in-memory cache for config-like files that the caller specifies (i.e., files like `.gitmodules`, `~/.gitconfig` etc.). Add two external functions `git_configset_get_value` and `git_configset_get_value_multi` for querying from the config sets. `git_configset_get_value` follows `last one wins` semantic (i.e. if there are multiple matches for the queried key in the files of the configset the value returned will be the last entry in `value_list`). `git_configset_get_value_multi` returns a list of values sorted in order of increasing priority (i.e. last match will be at the end of the list). Add type specific query functions like `git_configset_get_bool` and similar. Add a default `config_set`, `the_config_set` to cache all key-value pairs read from usual config files (repo specific .git/config, user wide ~/.gitconfig, XDG config and the global /etc/gitconfig). `the_config_set` is populated using `git_config()`. Add two external functions `git_config_get_value` and `git_config_get_value_multi` for querying in a non-callback manner from `the_config_set`. Also, add type specific query functions that are implemented as a thin wrapper around the `config_set` API. 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>
-
- 25 7月, 2014 1 次提交
-
-
由 Jeff King 提交于
When we see the core.commentchar config option, we extract the string with git_config_string, which does two things: 1. It complains via config_error_nonbool if there is no string value. 2. It makes a copy of the string. Since we immediately parse the string into its single-character value, we only care about (1). And in fact (2) is a detriment, as it means we leak the copy. Instead, let's just check the pointer value ourselves, and parse directly from the const string we already have. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 17 7月, 2014 1 次提交
-
-
由 Karsten Blees 提交于
There is no fchmod() on native Windows platforms (MinGW and MSVC), and the equivalent Win32 API (SetFileInformationByHandle) requires Windows Vista. Use chmod() instead. Signed-off-by: NKarsten Blees <blees@dcon.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 21 6月, 2014 1 次提交
-
-
由 Jeff King 提交于
The skip_prefix() function returns a pointer to the content past the prefix, or NULL if the prefix was not found. While this is nice and simple, in practice it makes it hard to use for two reasons: 1. When you want to conditionally skip or keep the string as-is, you have to introduce a temporary variable. For example: tmp = skip_prefix(buf, "foo"); if (tmp) buf = tmp; 2. It is verbose to check the outcome in a conditional, as you need extra parentheses to silence compiler warnings. For example: if ((cp = skip_prefix(buf, "foo")) /* do something with cp */ Both of these make it harder to use for long if-chains, and we tend to use starts_with() instead. However, the first line of "do something" is often to then skip forward in buf past the prefix, either using a magic constant or with an extra strlen(3) (which is generally computed at compile time, but means we are repeating ourselves). This patch refactors skip_prefix() to return a simple boolean, and to provide the pointer value as an out-parameter. If the prefix is not found, the out-parameter is untouched. This lets you write: if (skip_prefix(arg, "foo ", &arg)) do_foo(arg); else if (skip_prefix(arg, "bar ", &arg)) do_bar(arg); Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 28 5月, 2014 2 次提交
-
-
由 Brian Gesiak 提交于
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: NBrian Gesiak <modocache@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Øystein Walle 提交于
git_config_string() does not handle '~' and '~user' as part of the value. Using git_config_pathname() fixes this. Signed-off-by: NØystein Walle <oystwa@gmail.com> Reviewed-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 24 5月, 2014 1 次提交
-
-
由 Jeff King 提交于
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: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 20 5月, 2014 2 次提交
-
-
由 Nguyễn Thái Ngọc Duy 提交于
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: 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 提交于
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 eff80a9f (Allow custom "comment char" - 2013-01-16). It's not clear to me _why_ that behavior is wanted. Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 07 5月, 2014 1 次提交
-
-
由 Eric Wong 提交于
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: NEric Wong <normalperson@yhbt.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 17 4月, 2014 1 次提交
-
-
由 Jeff King 提交于
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: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 19 2月, 2014 3 次提交
-
-
由 Kirill A. Shutemov 提交于
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: NKirill A. Shutemov <kirill@shutemov.name> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Kirill A. Shutemov 提交于
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: NKirill A. Shutemov <kirill@shutemov.name> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jeff King 提交于
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: NJeff King <peff@peff.net> Signed-off-by: NKirill A. Shutemov <kirill@shutemov.name> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 29 1月, 2014 1 次提交
-
-
由 Jeff King 提交于
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: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 07 12月, 2013 1 次提交
-
-
由 Thomas Rast 提交于
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: NJess Hottenstein <jess.hottenstein@gmail.com> Signed-off-by: NThomas Rast <tr@thomasrast.ch> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 06 12月, 2013 1 次提交
-
-
由 Christian Couder 提交于
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: NChristian Couder <chriscool@tuxfamily.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 15 10月, 2013 1 次提交
-
-
由 Ramsay Jones 提交于
Commit 7192777d 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: NRamsay Jones <ramsay@ramsay1.demon.co.uk> Explained-by: NJeff King <peff@peff.net> Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
-
- 10 9月, 2013 1 次提交
-
-
由 Jeff King 提交于
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: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-