path: root/config.c
AgeCommit message (Collapse)Author
2011-11-21config.c: Fix a static buffer overwrite bug by avoiding mkpath()Ramsay Jones
On cygwin, test number 21 of (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 <> Signed-off-by: Junio C Hamano <>
2011-10-18Merge branch 'bc/attr-ignore-case'Junio C Hamano
* 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
2011-10-06attr: read core.attributesfile from git_default_core_configJunio C Hamano
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 <> Signed-off-by: Junio C Hamano <>
2011-10-05Merge branch 'rr/revert-cherry-pick-continue'Junio C Hamano
* 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
2011-08-05Merge branch 'jc/pack-order-tweak'Junio C Hamano
* jc/pack-order-tweak: pack-objects: optimize "recency order" core: log offset pack data accesses happened
2011-08-04config: Introduce functions to write non-standard fileRamkumar Ramachandra
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 <> Helped-by: Jonathan Nieder <> Reviewed-by: Jonathan Nieder <> Signed-off-by: Ramkumar Ramachandra <> Signed-off-by: Junio C Hamano <>
2011-07-22Merge branch 'maint'Junio C Hamano
* 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
2011-07-19git-config: Remove extra whitespacesPavan Kumar Sunkara
Remove extra whitespaces introduced by commits 01ebb9dc and fc1905bb Signed-off-by: Pavan Kumar Sunkara <> Signed-off-by: Junio C Hamano <>
2011-07-19Merge branch 'jk/clone-cmdline-config'Junio C Hamano
* 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
2011-07-19Merge branch 'jk/maint-config-param'Junio C Hamano
* 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
2011-07-07core: log offset pack data accesses happenedJunio C Hamano
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 <>
2011-06-22config: make git_config_parse_parameter a public functionJeff King
We use this internally to parse "git -c", but the general format of "key=value" is useful for other places. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2011-06-22config: use strbuf_split_str instead of a temporary strbufJeff King
This saves an allocation and copy, and also fixes a minor memory leak. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2011-06-22config: avoid segfault when parsing command-line configJeff King
We already check for an empty key on the left side of an equals, but we would segfault if there was no content at all. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2011-06-22config: die on error in command-line configJeff King
The error handling for git_config is somewhat confusing. We collect errors from running git_config_from_file on the various config files and carefully pass them back up. But the two odd things are: 1. We actually die on most errors in git_config_from_file. In fact, the only error we actually pass back up is if fopen() fails on the file. 2. Most callers of git_config do not check the error return at all, but will continue if git_config reports an error. When the code for "git -c" was added, it dutifully passed errors up the call stack, only for them to be eventually ignored. This makes it inconsistent with the file-parsing code, which will die when it sees malformed config. And it's somewhat unsafe, because it means an error in parsing a typo like: git -c clean.requireforce=ture clean will continue the command, ignoring the config the user tried to give. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2011-06-22fix "git -c" parsing of values with equals signsJeff King
If you do something like: git -c"value with = in it" ... we would split your option on "=" into three fields and throw away the third one. With this patch we correctly take everything after the first "=" as the value (keys cannot have an equals sign in them, so the parsing is unambiguous). Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2011-06-16config.c: Make git_config() work correctly when called recursivelyRamsay Jones
On Cygwin, this fixes a test failure in (test 98, "git notes copy --for-rewrite (disabled)"). The test failure is caused by a recursive call to git_config() which has the effect of skipping to the end-of-file while processing the "notes.rewriteref" config variable. Thus, any config variables that appear after "notes.rewriteref" are simply ignored by git_config(). Also, we note that the original FILE handle is leaked as a result of the recursive call. The recursive call to git_config() is due to the "schizophrenic stat" functions on cygwin, where one of two different implementations of the l/stat functions is selected lazily, depending on some config variables. In this case, the init_copy_notes_for_rewrite() function calls git_config() with the notes_rewrite_config() callback function. This callback, while processing the "notes.rewriteref" variable, in turn calls string_list_add_refs_by_glob() to process the associated ref value. This eventually leads to a call to the get_ref_dir() function, which in turn calls stat(). On cygwin, the stat() macro leads to an indirect call to cygwin_stat_stub() which, via init_stat(), then calls git_config() in order to determine which l/stat implementation to bind to. In order to solve this problem, we modify git_config() so that the global state variables used by the config reading code is packaged up and managed on a local state stack. Signed-off-by: Ramsay Jones <> Signed-off-by: Junio C Hamano <>
2011-06-01Merge branch 'jk/maint-config-alias-fix' into maintJunio C Hamano
* jk/maint-config-alias-fix: handle_options(): do not miscount how many arguments were used config: always parse GIT_CONFIG_PARAMETERS during git_config git_config: don't peek at global config_parameters config: make environment parsing routines static
2011-05-31config.c: Remove unused git_config_global() functionRamsay Jones
Commit 8f323c00 (drop support for GIT_CONFIG_NOGLOBAL, 15-03-2011) removed the git_config_global() function, among other things, since it is no longer required. Unfortunately, this function has since been unintentionally restored by a faulty conflict resolution. Remove it. Signed-off-by: Ramsay Jones <> Signed-off-by: Junio C Hamano <>
2011-05-31Merge branch 'jk/maint-config-alias-fix'Junio C Hamano
* jk/maint-config-alias-fix: handle_options(): do not miscount how many arguments were used config: always parse GIT_CONFIG_PARAMETERS during git_config git_config: don't peek at global config_parameters config: make environment parsing routines static Conflicts: config.c
2011-05-24config: always parse GIT_CONFIG_PARAMETERS during git_configJeff King
Previously we parsed GIT_CONFIG_PARAMETERS lazily into a linked list, and then checked that list during future invocations of git_config. However, that ignores the fact that the environment variable could change during our run (e.g., because we parse more "-c" as part of an alias). Instead, let's just re-parse the environment variable each time. It's generally not very big, and it's no more work than parsing the config files, anyway. As a bonus, we can ditch all of the linked list storage code entirely, making the code much simpler. The test unfortunately still does not pass because of an unrelated bug in handle_options. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2011-05-24git_config: don't peek at global config_parametersJeff King
The config_parameters list in config.c is an implementation detail of git_config_from_parameters; instead, that function should tell us whether it found anything. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2011-05-24config: make environment parsing routines staticJeff King
Nobody outside of git_config_from_parameters should need to use the GIT_CONFIG_PARAMETERS parsing functions, so let's make them private. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2011-05-18config: define and document exit codesMichael J Gruber
The return codes of git_config_set() and friends are magic numbers right in the source. #define them in cache.h where the functions are declared, and use the constants in the source. Also, mention the resulting exit codes of "git config" in its man page (and complete the list). Signed-off-by: Michael J Gruber <> Signed-off-by: Junio C Hamano <>
2011-05-09convert: rename the "eol" global variable to "core_eol"Junio C Hamano
Yes, it is clear that "eol" wants to mean some sort of end-of-line thing, but as the name of a global variable, it is way too short to describe what kind of end-of-line thing it wants to represent. Besides, there are many codepaths that want to use their own local "char *eol" variable to point at the end of the current line they are processing. This global variable holds what we read from core.eol configuration variable. Name it as such. Signed-off-by: Junio C Hamano <>
2011-05-04Merge branch 'jc/pack-objects-bigfile' into maintJunio C Hamano
* jc/pack-objects-bigfile: Teach core.bigfilethreashold to pack-objects
2011-04-27Merge branch 'ef/maint-strbuf-init'Junio C Hamano
* ef/maint-strbuf-init: config: support values longer than 1023 bytes strbuf: make sure buffer is zero-terminated
2011-04-27Merge branch 'jc/pack-objects-bigfile'Junio C Hamano
* jc/pack-objects-bigfile: Teach core.bigfilethreashold to pack-objects
2011-04-11config: support values longer than 1023 bytesErik Faye-Lund
parse_value in config.c has a static buffer of 1024 bytes that it parse the value into. This can sometimes be a problem when a config file contains very long values. It's particularly amusing that git-config already is able to write such files, so it should probably be able to read them as well. Fix this by using a strbuf instead of a fixed-size buffer. Signed-off-by: Erik Faye-Lund <> Acked-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2011-04-06Teach core.bigfilethreashold to pack-objectsJunio C Hamano
The pack-objects command should take notice of the object file and refrain from attempting to delta large ones, to be consistent with the fast-import command. Signed-off-by: Junio C Hamano <>
2011-03-23Merge branch 'lt/default-abbrev'Junio C Hamano
* lt/default-abbrev: Rename core.abbrevlength back to core.abbrev Make the default abbrev length configurable
2011-03-23Merge branch 'jn/test-sanitize-git-env'Junio C Hamano
* jn/test-sanitize-git-env: tests: scrub environment of GIT_* variables config: drop support for GIT_CONFIG_NOGLOBAL gitattributes: drop support for GIT_ATTR_NOGLOBAL tests: suppress system gitattributes tests: stop worrying about obsolete environment variables
2011-03-21Rename core.abbrevlength back to core.abbrevJunio C Hamano
It corresponds to --abbrev=$n command line option after all. Signed-off-by: Junio C Hamano <>
2011-03-16Merge branch 'maint'Junio C Hamano
* maint: Prepare draft release notes to gitweb: highlight: replace tabs with spaces make_absolute_path: return the input path if it points to our buffer valgrind: ignore SSE-based strlen invalid reads diff --submodule: split into bite-sized pieces cherry: split off function to print output lines branch: split off function that writes tracking info and commit subject standardize brace placement in struct definitions compat: make gcc bswap an inline function enums: omit trailing comma for portability Conflicts: RelNotes
2011-03-16Merge branch 'jh/push-default-upstream-configname' into maintJunio C Hamano
* jh/push-default-upstream-configname: push.default: Rename 'tracking' to 'upstream'
2011-03-16standardize brace placement in struct definitionsJonathan Nieder
In a struct definitions, unlike functions, the prevailing style is for the opening brace to go on the same line as the struct name, like so: struct foo { int bar; char *baz; }; Indeed, grepping for 'struct [a-z_]* {$' yields about 5 times as many matches as 'struct [a-z_]*$'. Linus sayeth: Heretic people all over the world have claimed that this inconsistency is ... well ... inconsistent, but all right-thinking people know that (a) K&R are _right_ and (b) K&R are right. Signed-off-by: Jonathan Nieder <> Signed-off-by: Junio C Hamano <>
2011-03-15config: drop support for GIT_CONFIG_NOGLOBALJonathan Nieder
Now that test-lib sets $HOME to protect against pollution from user settings, GIT_CONFIG_NOGLOBAL is not needed for use by the test suite any more. And as luck would have it, a quick code search reveals no other users in the wild. This patch does not affect GIT_CONFIG_NOSYSTEM, which is still needed. Helped-by: Jeff King <> Signed-off-by: Jonathan Nieder <> Signed-off-by: Junio C Hamano <>
2011-03-11Make the default abbrev length configurableLinus Torvalds
The default of 7 comes from fairly early in git development, when seven hex digits was a lot (it covers about 250+ million hash values). Back then I thought that 65k revisions was a lot (it was what we were about to hit in BK), and each revision tends to be about 5-10 new objects or so, so a million objects was a big number. These days, the kernel isn't even the largest git project, and even the kernel has about 220k revisions (_much_ bigger than the BK tree ever was) and we are approaching two million objects. At that point, seven hex digits is still unique for a lot of them, but when we're talking about just two orders of magnitude difference between number of objects and the hash size, there _will_ be collisions in truncated hash values. It's no longer even close to unrealistic - it happens all the time. We should both increase the default abbrev that was unrealistically small, _and_ add a way for people to set their own default per-project in the git config file. This is the first step to first make it configurable; the default of 7 is not raised yet. Signed-off-by: Junio C Hamano <>
2011-03-11Merge branch 'maint'Junio C Hamano
* maint: Revert "core.abbrevguard: Ensure short object names stay unique a bit longer"
2011-03-11Revert "core.abbrevguard: Ensure short object names stay unique a bit longer"Junio C Hamano
This reverts commit 72a5b561fc1c4286bc7c5b0693afc076af261e1f, as adding fixed number of hexdigits more than necessary to make one object name locally unique does not help in futureproofing the uniqueness of names we generate today. Signed-off-by: Junio C Hamano <>
2011-02-28Merge branch 'jh/push-default-upstream-configname'Junio C Hamano
* jh/push-default-upstream-configname: push.default: Rename 'tracking' to 'upstream'
2011-02-22Disallow empty section and variable namesLibor Pechacek
It is possible to break your repository config by creating an invalid key. The config parser in turn chokes on it: $ git init Initialized empty Git repository in /tmp/gittest/.git/ $ git config .foo false $ git config core.bare fatal: bad config file line 6 in .git/config This patch makes git-config reject keys which start or end with a dot and adds tests for these cases. Signed-off-by: Libor Pechacek <> Signed-off-by: Junio C Hamano <>
2011-02-22Sanity-check config variable namesLibor Pechacek
Sanity-check config variable names when adding and retrieving them. As a side effect code duplication between git_config_set_multivar and get_value (in builtin/config.c) was removed and the common functionality was placed in git_config_parse_key. This breaks a test in t1300 which used invalid section-less keys in the tests for "git -c". However, allowing such names there was useless, since there was no way to set them via config file, and no part of git actually tried to use section-less keys. This patch updates the test to use more realistic examples as well as adding its own test. Signed-off-by: Libor Pechacek <> Acked-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2011-02-16push.default: Rename 'tracking' to 'upstream'Johan Herland
Users are sometimes confused with two different types of "tracking" behavior in Git: "remote-tracking" branches (e.g. refs/remotes/*/*) versus the merge/rebase relationship between a local branch and its @{upstream} (controlled by and config settings). When the push.default is set to 'tracking', it specifies that a branch should be pushed to its @{upstream} branch. In other words, setting push.default to 'tracking' applies only to the latter of the above two types of "tracking" behavior. In order to make this more understandable to the user, we rename the push.default == 'tracking' option to push.default == 'upstream'. push.default == 'tracking' is left as a deprecated synonym for 'upstream'. Signed-off-by: Johan Herland <> Signed-off-by: Junio C Hamano <>
2010-12-28Merge branch 'nd/setup'Junio C Hamano
* nd/setup: (47 commits) setup_work_tree: adjust relative $GIT_WORK_TREE after moving cwd git.txt: correct where --work-tree path is relative to Revert "Documentation: always respect core.worktree if set" t0001: test git init when run via an alias Remove all logic from get_git_work_tree() setup: rework setup_explicit_git_dir() setup: clean up setup_discovered_git_dir() t1020-subdirectory: test alias expansion in a subdirectory setup: clean up setup_bare_git_dir() setup: limit get_git_work_tree()'s to explicit setup case only Use git_config_early() instead of git_config() during repo setup Add git_config_early() git-rev-parse.txt: clarify --git-dir t1510: setup case #31 t1510: setup case #30 t1510: setup case #29 t1510: setup case #28 t1510: setup case #27 t1510: setup case #26 t1510: setup case #25 ...
2010-12-22Add git_config_early()Nguyễn Thái Ngọc Duy
This version of git_config() will be used during repository setup. As a repository is being set up, $GIT_DIR is not nailed down yet, git_pathdup() should not be used to get $GIT_DIR/config. Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2010-12-21Merge branch 'jk/maint-decorate-01-bool'Junio C Hamano
* jk/maint-decorate-01-bool: handle arbitrary ints in git_config_maybe_bool
2010-12-19handle arbitrary ints in git_config_maybe_boolJeff King
This function recently gained the ability to recognize the documented "0" and "1" values as false/true. However, unlike regular git_config_bool, it did not treat arbitrary non-zero numbers as true. While this is undocumented and probably ridiculous for somebody to rely on, it is safer to behave exactly as git_config_bool would. Because git_config_maybe_bool can be used to retrofit new non-bool values onto existing bool options, not behaving in exactly the same way is technically a regression. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2010-12-08Merge branch 'jk/maint-decorate-01-bool'Junio C Hamano
* jk/maint-decorate-01-bool: log.decorate: accept 0/1 bool values
2010-12-04Merge branch 'jc/abbrev-guard'Junio C Hamano
* jc/abbrev-guard: core.abbrevguard: Ensure short object names stay unique a bit longer