summaryrefslogtreecommitdiff
path: root/config.c
Commit message (Collapse)AuthorAgeFilesLines
* Merge branch 'jk/config-parsing-cleanup'Junio C Hamano2013-02-041-0/+33
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-231-0/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-041-0/+8
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | 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"
| * | Allow custom "comment char"Junio C Hamano2013-01-161-0/+8
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some users do want to write a line that begin with a pound sign, #, in their commit log message. Many tracking system recognise a token of #<bugid> form, for example. The support we offer these use cases is not very friendly to the end users. They have a choice between - Don't do it. Avoid such a line by rewrapping or indenting; and - Use --cleanup=whitespace but remove all the hint lines we add. Give them a way to set a custom comment char, e.g. $ git -c core.commentchar="%" commit so that they do not have to do either of the two workarounds. [jc: although I started the topic, all the tests and documentation updates, many of the call sites of the new strbuf_add_commented_*() functions, and the change to git-submodule.sh scripted Porcelain are from Ralf.] Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Enable minimal stat checkingRobin Rosenberg2013-01-221-0/+6
|/ | | | | | | | | | | | | | | | | | | Specifically the fields uid, gid, ctime, ino and dev are set to zero by JGit. Other implementations, eg. Git in cygwin are allegedly also somewhat incompatible with Git For Windows and on *nix platforms the resolution of the timestamps may differ. Any stat checking by git will then need to check content, which may be very slow, particularly on Windows. Since mtime and size is typically enough we should allow the user to tell git to avoid checking these fields if they are set to zero in the index. This change introduces a core.checkstat config option where the the user can select to check all fields (default), or just size and the whole second part of mtime (minimal). Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'jn/warn-on-inaccessible-loosen'Junio C Hamano2013-01-061-5/+5
|\ | | | | | | | | | | | | | | | | | | | | Deal with a situation where .config/git is a file and we notice .config/git/config is not readable due to ENOTDIR, not ENOENT. * jn/warn-on-inaccessible-loosen: config: exit on error accessing any config file doc: advertise GIT_CONFIG_NOSYSTEM config: treat user and xdg config permission problems as errors config, gitignore: failure to access with ENOTDIR is ok
| * config: exit on error accessing any config fileJonathan Nieder2012-10-141-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is convenience in warning and moving on when somebody has a bogus permissions on /etc/gitconfig and cannot do anything about it. But the cost in predictability and security is too high --- when unreadable config files are skipped, it means an I/O error or permissions problem causes important configuration to be bypassed. For example, servers may depend on /etc/gitconfig to enforce security policy (setting transfer.fsckObjects or receive.deny*). Best to always error out when encountering trouble accessing a config file. This may add inconvenience in some cases: 1. You are inspecting somebody else's repo, and you do not have access to their .git/config file. Git typically dies in this case already since we cannot read core.repositoryFormatVersion, so the change should not be too noticeable. 2. You have used "sudo -u" or a similar tool to switch uid, and your environment still points Git at your original user's global config, which is not readable. In this case people really would be inconvenienced (they would rather see the harmless warning and continue the operation) but they can work around it by setting HOME appropriately after switching uids. 3. You do not have access to /etc/gitconfig due to a broken setup. In this case, erroring out is a good way to put pressure on the sysadmin to fix the setup. While they wait for a reply, users can set GIT_CONFIG_NOSYSTEM to true to keep Git working without complaint. After this patch, errors accessing the repository-local and systemwide config files and files requested in include directives cause Git to exit, just like errors accessing ~/.gitconfig. Explained-by: Jeff King <peff@peff.net> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * config: treat user and xdg config permission problems as errorsJonathan Nieder2012-10-131-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Git reads multiple configuration files: settings come first from the system config file (typically /etc/gitconfig), then the xdg config file (typically ~/.config/git/config), then the user's dotfile (~/.gitconfig), then the repository configuration (.git/config). Git has always used access(2) to decide whether to use each file; as an unfortunate side effect, that means that if one of these files is unreadable (e.g., EPERM or EIO), git skips it. So if I use ~/.gitconfig to override some settings but make a mistake and give it the wrong permissions then I am subject to the settings the sysadmin chose for /etc/gitconfig. Better to error out and ask the user to correct the problem. This only affects the user and xdg config files, since the user presumably has enough access to fix their permissions. If the system config file is unreadable, the best we can do is to warn about it so the user knows to notify someone and get on with work in the meantime. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'jk/error-const-return'Junio C Hamano2013-01-051-0/+1
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | Help compilers' flow analysis by making it more explicit that error() always returns -1, to reduce false "variable used uninitialized" warnings. Looks somewhat ugly but not too much. * jk/error-const-return: silence some -Wuninitialized false positives make error()'s constant return value more visible
| * | silence some -Wuninitialized false positivesJeff King2012-12-151-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are a few error functions that simply wrap error() and provide a standardized message text. Like error(), they always return -1; knowing that can help the compiler silence some false positive -Wuninitialized warnings. One strategy would be to just declare these as inline in the header file so that the compiler can see that they always return -1. However, gcc does not always inline them (e.g., it will not inline opterror, even with -O3), which renders our change pointless. Instead, let's follow the same route we did with error() in the last patch, and define a macro that makes the constant return value obvious to the compiler. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | mailmap: support reading mailmap from blobsJeff King2012-12-121-0/+2
|/ / | | | | | | | | | | | | | | | | | | | | In a bare repository, there isn't a simple way to respect an in-tree mailmap without extracting it to a temporary file. This patch provides a config variable, similar to mailmap.file, which reads the mailmap from a blob in the repository. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'jk/config-ignore-duplicates'Junio C Hamano2012-11-211-0/+1
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Drop duplicate detection from "git-config --get"; this lets it better match the internal config callbacks, which clears up some corner cases with includes. * jk/config-ignore-duplicates: builtin/config.c: Fix a sparse warning git-config: use git_config_with_options git-config: do not complain about duplicate entries git-config: collect values instead of immediately printing git-config: fix regexp memory leaks on error conditions git-config: remove memory leak of key regexp t1300: test "git config --get-all" more thoroughly t1300: remove redundant test t1300: style updates
| * | git-config: fix regexp memory leaks on error conditionsJeff King2012-10-241-0/+1
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The get_value function has a goto label for cleaning up on errors, but it only cleans up half of what the function might allocate. Let's also clean up the key and regexp variables there. Note that we need to take special care when compiling the regex fails to clean it up ourselves, since it is in a half-constructed state (we would want to free it, but not regfree it). Similarly, we fix git_config_parse_key to return NULL when it fails, not a pointer to some already-freed memory. Signed-off-by: Jeff King <peff@peff.net>
* | Remove the hard coded length limit on variable names in config filesBen Walton2012-10-011-30/+29
|/ | | | | | | | | | | | | | | | | | | | | | | | | | Previously while reading the variable names in config files, there was a 256 character limit with at most 128 of those characters being used by the section header portion of the variable name. This limitation was only enforced while reading the config files. It was possible to write a config file that was not subsequently readable. Instead of enforcing this limitation for both reading and writing, remove it entirely by changing the var member of the config_file struct to a strbuf instead of a fixed length buffer. Update all of the parsing functions in config.c to use the strbuf instead of the static buffer. The parsing functions that returned the base length of the variable name now return simply 0 for success and -1 for failure. The base length information is obtained through the strbuf's len member. We now send the buf member of the strbuf to external callback functions to preserve the external api. None of the external callers rely on the old size limitation for sizing their own buffers so removing the limit should have no externally visible effect. Signed-off-by: Ben Walton <bdwalton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* config: warn on inaccessible filesJeff King2012-08-211-5/+5
| | | | | | | | | | | | | | | Before reading a config file, we check "!access(path, R_OK)" to make sure that the file exists and is readable. If it's not, then we silently ignore it. For the case of ENOENT, this is fine, as the presence of the file is optional. For other cases, though, it may indicate a configuration error (e.g., not having permissions to read the file). Let's print a warning in these cases to let the user know. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'mm/config-xdg'Junio C Hamano2012-07-221-2/+2
|\ | | | | | | | | * mm/config-xdg: config: fix several access(NULL) calls
| * config: fix several access(NULL) callsMatthieu Moy2012-07-161-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | When $HOME is unset, home_config_paths fails and returns NULL pointers for user_config and xdg_config. Valgrind complains with Syscall param access(pathname) points to unaddressable byte(s). Don't call blindly access() on these variables, but test them for NULL-ness before. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'tb/sanitize-decomposed-utf-8-pathname'Junio C Hamano2012-07-131-0/+5
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | Teaches git to normalize pathnames read from readdir(3) and all arguments from the command line into precomposed UTF-8 (assuming that they come as decomposed UTF-8) to work around issues on Mac OS. I think there still are other places that need conversion (e.g. paths that are read from stdin for some commands), but this should be a good first step in the right direction. * tb/sanitize-decomposed-utf-8-pathname: git on Mac OS and precomposed unicode
| * git on Mac OS and precomposed unicodeTorsten Bögershausen2012-07-081-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Mac OS X mangles file names containing unicode on file systems HFS+, VFAT or SAMBA. When a file using unicode code points outside ASCII is created on a HFS+ drive, the file name is converted into decomposed unicode and written to disk. No conversion is done if the file name is already decomposed unicode. Calling open("\xc3\x84", ...) with a precomposed "Ä" yields the same result as open("\x41\xcc\x88",...) with a decomposed "Ä". As a consequence, readdir() returns the file names in decomposed unicode, even if the user expects precomposed unicode. Unlike on HFS+, Mac OS X stores files on a VFAT drive (e.g. an USB drive) in precomposed unicode, but readdir() still returns file names in decomposed unicode. When a git repository is stored on a network share using SAMBA, file names are send over the wire and written to disk on the remote system in precomposed unicode, but Mac OS X readdir() returns decomposed unicode to be compatible with its behaviour on HFS+ and VFAT. The unicode decomposition causes many problems: - The names "git add" and other commands get from the end user may often be precomposed form (the decomposed form is not easily input from the keyboard), but when the commands read from the filesystem to see what it is going to update the index with already is on the filesystem, readdir() will give decomposed form, which is different. - Similarly "git log", "git mv" and all other commands that need to compare pathnames found on the command line (often but not always precomposed form; a command line input resulting from globbing may be in decomposed) with pathnames found in the tree objects (should be precomposed form to be compatible with other systems and for consistency in general). - The same for names stored in the index, which should be precomposed, that may need to be compared with the names read from readdir(). NFS mounted from Linux is fully transparent and does not suffer from the above. As Mac OS X treats precomposed and decomposed file names as equal, we can - wrap readdir() on Mac OS X to return the precomposed form, and - normalize decomposed form given from the command line also to the precomposed form, to ensure that all pathnames used in Git are always in the precomposed form. This behaviour can be requested by setting "core.precomposedunicode" configuration variable to true. The code in compat/precomposed_utf8.c implements basically 4 new functions: precomposed_utf8_opendir(), precomposed_utf8_readdir(), precomposed_utf8_closedir() and precompose_argv(). The first three are to wrap opendir(3), readdir(3), and closedir(3) functions. The argv[] conversion allows to use the TAB filename completion done by the shell on command line. It tolerates other tools which use readdir() to feed decomposed file names into git. When creating a new git repository with "git init" or "git clone", "core.precomposedunicode" will be set "false". The user needs to activate this feature manually. She typically sets core.precomposedunicode to "true" on HFS and VFAT, or file systems mounted via SAMBA. Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | config: read (but not write) from $XDG_CONFIG_HOME/git/config fileHuynh Khoi Nguyen Nguyen2012-06-251-9/+14
|/ | | | | | | | | | | | | | | | | | | | | | | | | Teach git to read the "gitconfig" information from a new location, $XDG_CONFIG_HOME/git/config; this allows the user to avoid cluttering $HOME with many per-application configuration files. In the order of reading, this file comes between the global configuration file (typically $HOME/.gitconfig) and the system wide configuration file (typically /etc/gitconfig). We do not write to this new location (yet). If $XDG_CONFIG_HOME is either not set or empty, $HOME/.config/git/config will be used. This is in line with XDG specification. If the new file does not exist, the behavior is unchanged. Signed-off-by: Huynh Khoi Nguyen Nguyen <Huynh-Khoi-Nguyen.Nguyen@ensimag.imag.fr> Signed-off-by: Valentin Duperray <Valentin.Duperray@ensimag.imag.fr> Signed-off-by: Franck Jonas <Franck.Jonas@ensimag.imag.fr> Signed-off-by: Lucien Kong <Lucien.Kong@ensimag.imag.fr> Signed-off-by: Thomas Nguy <Thomas.Nguy@ensimag.imag.fr> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* move identity config parsing to ident.cJeff King2012-05-221-23/+1
| | | | | | | | | There's no reason for this to be in config, except that once upon a time all of the config parsing was there. It makes more sense to keep the ident code together. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'mm/simple-push'Junio C Hamano2012-05-021-2/+4
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | New users tend to work on one branch at a time and push the result out. The current and upstream modes of push is a more suitable default mode than matching mode for these people, but neither is surprise-free depending on how the project is set up. Introduce a "simple" mode that is a subset of "upstream" but only works when the branch is named the same between the remote and local repositories. The plan is to make it the new default when push.default is not configured. By Matthieu Moy (5) and others * mm/simple-push: push.default doc: explain simple after upstream push: document the future default change for push.default (matching -> simple) t5570: use explicit push refspec push: introduce new push.default mode "simple" t5528-push-default.sh: add helper functions Undocument deprecated alias 'push.default=tracking' Documentation: explain push.default option a bit more
| * push: introduce new push.default mode "simple"Matthieu Moy2012-04-241-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When calling "git push" without argument, we want to allow Git to do something simple to explain and safe. push.default=matching is unsafe when used to push to shared repositories, and hard to explain to beginners in some contexts. It is debatable whether 'upstream' or 'current' is the safest or the easiest to explain, so introduce a new mode called 'simple' that is the intersection of them: push to the upstream branch, but only if it has the same name remotely. If not, give an error that suggests the right command to push explicitely to 'upstream' or 'current'. A question is whether to allow pushing when no upstream is configured. An argument in favor of allowing the push is that it makes the new mode work in more cases. On the other hand, refusing to push when no upstream is configured encourages the user to set the upstream, which will be beneficial on the next pull. Lacking better argument, we chose to deny the push, because it will be easier to change in the future if someone shows us wrong. Original-patch-by: Jeff King <peff@peff.net> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'jk/maint-config-bogus-section'Junio C Hamano2012-04-301-1/+23
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | "git config --rename-section" to rename an existing section into a bogus one did not check the new name. By Jeff King * jk/maint-config-bogus-section: config: reject bogus section names for --rename-section
| * | config: reject bogus section names for --rename-sectionJeff King2012-04-251-1/+23
| |/ | | | | | | | | | | | | | | | | | | | | You can feed junk to "git config --rename-section", which will result in a config file that git will not even parse (so you cannot fix it with git-config). We already have syntactic sanity checks when setting a variable; let's do the same for section names. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | config: expand tildes in include.path variableJeff King2012-04-291-0/+6
|/ | | | | | | | | | | | You can already use relative paths in include.path, which means that including "foo" from your global "~/.gitconfig" will look in your home directory. However, you might want to do something clever like putting "~/.gitconfig-foo" in a specific repository's config file. Signed-off-by: Jeff King <peff@peff.net> Acked-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'ms/maint-config-error-at-eol-linecount'Junio C Hamano2012-03-131-4/+9
|\ | | | | | | | | | | | | | | | | | | | | | | | | When "git config" diagnoses an error in a configuration file and shows the line number for the offending line, it miscounted if the error was at the end of line. By Martin Stenberg * ms/maint-config-error-at-eol-linecount: config: report errors at the EOL with correct line number Conflicts: t/t1300-repo-config.sh
| * config: report errors at the EOL with correct line numberms/maint-config-error-at-eol-linecountMartin Stenberg2012-03-121-4/+9
| | | | | | | | | | | | | | | | | | | | | | | | A section in a config file with a missing "]" reports the next line as bad, same goes to a value with a missing end quote. This happens because the error is not detected until the end of the line, when line number is already increased. Fix this by decreasing line number by one for these cases. Signed-off-by: Martin Stenberg <martin@gnutiken.se> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | config: add include directiveJeff King2012-02-171-2/+73
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It can be useful to split your ~/.gitconfig across multiple files. For example, you might have a "main" file which is used on many machines, but a small set of per-machine tweaks. Or you may want to make some of your config public (e.g., clever aliases) while keeping other data back (e.g., your name or other identifying information). Or you may want to include a number of config options in some subset of your repos without copying and pasting (e.g., you want to reference them from the .git/config of participating repos). This patch introduces an include directive for config files. It looks like: [include] path = /path/to/file This is syntactically backwards-compatible with existing git config parsers (i.e., they will see it as another config entry and ignore it unless you are looking up include.path). The implementation provides a "git_config_include" callback which wraps regular config callbacks. Callers can pass it to git_config_from_file, and it will transparently follow any include directives, passing all of the discovered options to the real callback. Include directives are turned on automatically for "regular" git config parsing. This includes calls to git_config, as well as calls to the "git config" program that do not specify a single file (e.g., using "-f", "--global", etc). They are not turned on in other cases, including: 1. Parsing of other config-like files, like .gitmodules. There isn't a real need, and I'd rather be conservative and avoid unnecessary incompatibility or confusion. 2. Reading single files via "git config". This is for two reasons: a. backwards compatibility with scripts looking at config-like files. b. inspection of a specific file probably means you care about just what's in that file, not a general lookup for "do we have this value anywhere at all". If that is not the case, the caller can always specify "--includes". 3. Writing files via "git config"; we want to treat include.* variables as literal items to be copied (or modified), and not expand them. So "git config --unset-all foo.bar" would operate _only_ on .git/config, not any of its included files (just as it also does not operate on ~/.gitconfig). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | config: eliminate config_exclusive_filenameJeff King2012-02-171-7/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a magic global variable that was intended as an override to the usual git-config lookup process. Once upon a time, you could specify GIT_CONFIG to any git program, and it would look only at that file. This turned out to be confusing and cause a lot of bugs for little gain. As a result, dc87183 (Only use GIT_CONFIG in "git config", not other programs, 2008-06-30) took this away for all callers except git-config. Since git-config no longer uses it either, the variable can just go away. As the diff shows, nobody was setting to anything except NULL, so we can just replace any sites where it was read with NULL. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | config: provide a version of git_config with more optionsJeff King2012-02-171-4/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Callers may want to provide a specific version of a file in which to look for config. Right now this can be done by setting the magic global config_exclusive_filename variable. By providing a version of git_config that takes a filename, we can take a step towards making this magic global go away. Furthermore, by providing a more "advanced" interface, we now have a a natural place to add new options for callers like git-config, which care about tweaking the specifics of config lookup, without disturbing the large number of "simple" users (i.e., every other part of git). The astute reader of this patch may notice that the logic for handling config_exclusive_filename was taken out of git_config_early, but added into git_config. This means that git_config_early will no longer respect config_exclusive_filename. That's OK, because the only other caller of git_config_early is check_repository_format_gently, but the only function which sets config_exclusive_filename is cmd_config, which does not call check_repository_format_gently (and if it did, it would have been a bug, anyway, as we would be checking the repository format in the wrong file). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | config: teach git_config_rename_section a file argumentJeff King2012-02-171-7/+13
| | | | | | | | | | | | | | | | | | | | | | The other config-writing functions (git_config_set and git_config_set_multivar) each have an -"in_file" version to write a specific file. Let's add one for rename_section, with the eventual goal of moving away from the magic config_exclusive_filename global. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | config: teach git_config_set_multivar_in_file a default pathJeff King2012-02-171-13/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The git_config_set_multivar_in_file function takes a filename argument to specify the file into which the values should be written. Currently, this value must be non-NULL. Callers which want to write to the default location must use the regular, non-"in_file" version, which will either write to config_exclusive_filename, or to the repo config if the exclusive filename is NULL. Let's migrate the "default to using repo config" logic into the "in_file" form. That will let callers get the same default-if-NULL behavior as one gets with config_exclusive_filename, but without having to use the global variable. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'jc/stream-to-pack'Junio C Hamano2011-12-161-0/+4
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * jc/stream-to-pack: bulk-checkin: replace fast-import based implementation csum-file: introduce sha1file_checkpoint finish_tmp_packfile(): a helper function create_tmp_packfile(): a helper function write_pack_header(): a helper function Conflicts: pack.h
| * | bulk-checkin: replace fast-import based implementationjc/stream-to-packJunio C Hamano2011-12-011-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | This extends the earlier approach to stream a large file directly from the filesystem to its own packfile, and allows "git add" to send large files directly into a single pack. Older code used to spawn fast-import, but the new bulk-checkin API replaces it. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | Merge branch 'na/strtoimax'Junio C Hamano2011-12-051-10/+31
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | * na/strtoimax: Support sizes >=2G in various config options accepting 'g' sizes. Compatibility: declare strtoimax() under NO_STRTOUMAX Add strtoimax() compatibility function.
| * | | Support sizes >=2G in various config options accepting 'g' sizes.na/strtoimaxNick Alcock2011-11-051-10/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The config options core.packedGitWindowSize, core.packedGitLimit, core.deltaBaseCacheLimit, core.bigFileThreshold, pack.windowMemory and pack.packSizeLimit all claim to support suffixes up to and including 'g'. This implies that they should accept sizes >=2G on 64-bit systems: certainly, specifying a size of 3g should not silently be translated to zero or transformed into a large negative value due to integer overflow. However, due to use of git_config_int() rather than git_config_ulong(), that is exactly what happens: % git config core.bigFileThreshold 2g % git gc --aggressive # with extra debugging code to print out # core.bigfilethreshold after parsing bigfilethreshold: -2147483648 [...] This is probably irrelevant for core.deltaBaseCacheLimit, but is problematic for the other values. (It is particularly problematic for core.packedGitLimit, which can't even be set to its default value in the config file due to this bug.) This fixes things for 32-bit platforms as well. They get the usual bad config error if an overlarge value is specified, e.g.: fatal: bad config value for 'core.bigfilethreshold' in /home/nix/.gitconfig This is detected in all cases, even if the 32-bit platform has no size larger than 'long'. For signed integral configuration values, we also detect the case where the value is too large for the signed type but not the unsigned type. Signed-off-by: Nick Alcock <nix@esperi.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | config.c: Fix a static buffer overwrite bug by avoiding mkpath()Ramsay Jones2011-11-201-2/+2
| |/ / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On cygwin, test number 21 of t3200-branch.sh (git branch -m q q2 without config should succeed) fails. The failure involves the functions from path.c which parcel out internal static buffers from the git_path() and mkpath() functions. In particular, the rename_ref() function calls safe_create_leading\ _directories() with a filename returned by git_path("logs/%s", ref). safe_create_leading_directories(), in turn, calls stat() on each element of the path it is given. On cygwin, this leads to a call to git_config() for each component of the path, since this test explicitly removes the config file. git_config() calls mkpath(), so on the fourth component of the path, the original buffer passed into the function is overwritten with the config filename. Note that this bug is specific to cygwin and it's schizophrenic stat() functions (see commits adbc0b6, 7faee6b and 7974843). The lack of a config file and a path with at least four elements is also important to trigger the bug. In order to fix the problem, we replace the call to mkpath() with a call to mksnpath() and provide our own buffer. Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | Merge branch 'bc/attr-ignore-case'Junio C Hamano2011-10-171-0/+3
|\ \ \ | | |/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | * bc/attr-ignore-case: attr.c: respect core.ignorecase when matching attribute patterns attr: read core.attributesfile from git_default_core_config builtin/mv.c: plug miniscule memory leak cleanup: use internal memory allocation wrapper functions everywhere attr.c: avoid inappropriate access to strbuf "buf" member Conflicts: transport-helper.c
| * | attr: read core.attributesfile from git_default_core_configJunio C Hamano2011-10-061-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This code calls git_config from a helper function to parse the config entry it is interested in. Calling git_config in this way may cause a problem if the helper function can be called after a previous call to git_config by another function since the second call to git_config may reset some variable to the value in the config file which was previously overridden. The above is not a problem in this case since the function passed to git_config only parses one config entry and the variable it sets is not assigned outside of the parsing function. But a programmer who desires all of the standard config options to be parsed may be tempted to modify git_attr_config() so that it falls back to git_default_config() and then it _would_ be vulnerable to the above described behavior. So, move the call to git_config up into the top-level cmd_* function and move the responsibility for parsing core.attributesfile into the main config file parser. Which is only the logical thing to do ;-) Signed-off-by: Brandon Casey <drafnel@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | Merge branch 'rr/revert-cherry-pick-continue'Junio C Hamano2011-10-051-9/+27
|\ \ \ | |/ / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * rr/revert-cherry-pick-continue: builtin/revert.c: make commit_list_append() static revert: Propagate errors upwards from do_pick_commit revert: Introduce --continue to continue the operation revert: Don't implicitly stomp pending sequencer operation revert: Remove sequencer state when no commits are pending reset: Make reset remove the sequencer state revert: Introduce --reset to remove sequencer state revert: Make pick_commits functionally act on a commit list revert: Save command-line options for continuing operation revert: Save data for continuing after conflict resolution revert: Don't create invalid replay_opts in parse_args revert: Separate cmdline parsing from functional code revert: Introduce struct to keep command-line options revert: Eliminate global "commit" variable revert: Rename no_replay to record_origin revert: Don't check lone argument in get_encoding revert: Simplify and inline add_message_to_msg config: Introduce functions to write non-standard file advice: Introduce error_resolve_conflict
| * | config: Introduce functions to write non-standard fileRamkumar Ramachandra2011-08-041-9/+27
| |/ | | | | | | | | | | | | | | | | | | | | | | Introduce two new functions corresponding to "git_config_set" and "git_config_set_multivar" to write a non-standard configuration file. Expose these new functions in cache.h for other git programs to use. Helped-by: Jeff King <peff@peff.net> Helped-by: Jonathan Nieder <jrnieder@gmail.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'jc/pack-order-tweak'Junio C Hamano2011-08-051-0/+3
|\ \ | | | | | | | | | | | | | | | * jc/pack-order-tweak: pack-objects: optimize "recency order" core: log offset pack data accesses happened
| * | core: log offset pack data accesses happenedJunio C Hamano2011-07-061-0/+3
| |/ | | | | | | | | | | | | | | | | | | | | | | In a workload other than "git log" (without pathspec nor any option that causes us to inspect trees and blobs), the recency pack order is said to cause the access jump around quite a bit. Add a hook to allow us observe how bad it is. "git config core.logpackaccess /var/tmp/pal.txt" will give you the log in the specified file. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'maint'Junio C Hamano2011-07-221-2/+2
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | * maint: doc/fast-import: clarify notemodify command Documentation: minor grammatical fix in rev-list-options.txt Documentation: git-filter-branch honors replacement refs remote-curl: Add a format check to parsing of info/refs git-config: Remove extra whitespaces
| * | git-config: Remove extra whitespacesPavan Kumar Sunkara2011-07-191-2/+2
| |/ | | | | | | | | | | | | | | Remove extra whitespaces introduced by commits 01ebb9dc and fc1905bb Signed-off-by: Pavan Kumar Sunkara <pavan.sss1991@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'jk/clone-cmdline-config'Junio C Hamano2011-07-191-2/+2
|\ \ | | | | | | | | | | | | | | | | | | | | | * jk/clone-cmdline-config: clone: accept config options on the command line config: make git_config_parse_parameter a public function remote: use new OPT_STRING_LIST parse-options: add OPT_STRING_LIST helper
| * | config: make git_config_parse_parameter a public functionJeff King2011-06-221-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | We use this internally to parse "git -c core.foo=bar", but the general format of "key=value" is useful for other places. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | Merge branch 'jk/maint-config-param'Junio C Hamano2011-07-191-4/+4
|\ \ \ | |/ / | | | | | | | | | | | | | | | | | | | | | | | | * jk/maint-config-param: config: use strbuf_split_str instead of a temporary strbuf strbuf: allow strbuf_split to work on non-strbufs config: avoid segfault when parsing command-line config config: die on error in command-line config fix "git -c" parsing of values with equals signs strbuf_split: add a max parameter
| * | config: use strbuf_split_str instead of a temporary strbufJeff King2011-06-221-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | This saves an allocation and copy, and also fixes a minor memory leak. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
View Lorry Controller Status