summaryrefslogtreecommitdiff
path: root/config.c
AgeCommit message (Collapse)AuthorFilesLines
2012-03-13Merge branch 'ms/maint-config-error-at-eol-linecount'Libravatar Junio C Hamano1-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
2012-03-12config: report errors at the EOL with correct line numberLibravatar Martin Stenberg1-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>
2012-02-17config: add include directiveLibravatar Jeff King1-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>
2012-02-17config: eliminate config_exclusive_filenameLibravatar Jeff King1-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>
2012-02-17config: provide a version of git_config with more optionsLibravatar Jeff King1-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>
2012-02-17config: teach git_config_rename_section a file argumentLibravatar Jeff King1-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>
2012-02-17config: teach git_config_set_multivar_in_file a default pathLibravatar Jeff King1-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>
2011-12-16Merge branch 'jc/stream-to-pack'Libravatar Junio C Hamano1-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
2011-12-05Merge branch 'na/strtoimax'Libravatar Junio C Hamano1-10/+31
* na/strtoimax: Support sizes >=2G in various config options accepting 'g' sizes. Compatibility: declare strtoimax() under NO_STRTOUMAX Add strtoimax() compatibility function.
2011-12-01bulk-checkin: replace fast-import based implementationLibravatar Junio C Hamano1-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>
2011-11-20config.c: Fix a static buffer overwrite bug by avoiding mkpath()Libravatar Ramsay Jones1-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>
2011-11-05Support sizes >=2G in various config options accepting 'g' sizes.Libravatar Nick Alcock1-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>
2011-10-17Merge branch 'bc/attr-ignore-case'Libravatar Junio C Hamano1-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
2011-10-06attr: read core.attributesfile from git_default_core_configLibravatar Junio C Hamano1-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>
2011-10-05Merge branch 'rr/revert-cherry-pick-continue'Libravatar Junio C Hamano1-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
2011-08-05Merge branch 'jc/pack-order-tweak'Libravatar Junio C Hamano1-0/+3
* 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 fileLibravatar Ramkumar Ramachandra1-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>
2011-07-22Merge branch 'maint'Libravatar Junio C Hamano1-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
2011-07-19git-config: Remove extra whitespacesLibravatar Pavan Kumar Sunkara1-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>
2011-07-19Merge branch 'jk/clone-cmdline-config'Libravatar Junio C Hamano1-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
2011-07-19Merge branch 'jk/maint-config-param'Libravatar Junio C Hamano1-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
2011-07-06core: log offset pack data accesses happenedLibravatar Junio C Hamano1-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>
2011-06-22config: make git_config_parse_parameter a public functionLibravatar Jeff King1-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>
2011-06-22config: use strbuf_split_str instead of a temporary strbufLibravatar Jeff King1-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>
2011-06-22config: avoid segfault when parsing command-line configLibravatar Jeff King1-0/+2
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 <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-06-22config: die on error in command-line configLibravatar Jeff King1-1/+1
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 core.foo=bar" 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 <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-06-22fix "git -c" parsing of values with equals signsLibravatar Jeff King1-1/+1
If you do something like: git -c core.foo="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 <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-06-16config.c: Make git_config() work correctly when called recursivelyLibravatar Ramsay Jones1-30/+50
On Cygwin, this fixes a test failure in t3301-notes.sh (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 <ramsay@ramsay1.demon.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-06-01Merge branch 'jk/maint-config-alias-fix' into maintLibravatar Junio C Hamano1-42/+21
* 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() functionLibravatar Ramsay Jones1-5/+0
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 <ramsay@ramsay1.demon.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-30Merge branch 'jk/maint-config-alias-fix'Libravatar Junio C Hamano1-39/+23
* 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_configLibravatar Jeff King1-40/+11
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 <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-24git_config: don't peek at global config_parametersLibravatar Jeff King1-4/+11
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 <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-24config: make environment parsing routines staticLibravatar Jeff King1-2/+2
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 <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-17config: define and document exit codesLibravatar Michael J Gruber1-10/+10
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 <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-09convert: rename the "eol" global variable to "core_eol"Libravatar Junio C Hamano1-6/+6
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 <gitster@pobox.com>
2011-05-04Merge branch 'jc/pack-objects-bigfile' into maintLibravatar Junio C Hamano1-0/+6
* jc/pack-objects-bigfile: Teach core.bigfilethreashold to pack-objects
2011-04-27Merge branch 'ef/maint-strbuf-init'Libravatar Junio C Hamano1-10/+8
* 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'Libravatar Junio C Hamano1-0/+6
* jc/pack-objects-bigfile: Teach core.bigfilethreashold to pack-objects
2011-04-11config: support values longer than 1023 bytesLibravatar Erik Faye-Lund1-10/+8
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 <kusmabite@gmail.com> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-05Teach core.bigfilethreashold to pack-objectsLibravatar Junio C Hamano1-0/+6
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 <gitster@pobox.com>
2011-03-23Merge branch 'lt/default-abbrev'Libravatar Junio C Hamano1-0/+8
* lt/default-abbrev: Rename core.abbrevlength back to core.abbrev Make the default abbrev length configurable
2011-03-22Merge branch 'jn/test-sanitize-git-env'Libravatar Junio C Hamano1-6/+1
* 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-20Rename core.abbrevlength back to core.abbrevLibravatar Junio C Hamano1-1/+1
It corresponds to --abbrev=$n command line option after all. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-16Merge branch 'maint'Libravatar Junio C Hamano1-2/+1
* maint: Prepare draft release notes to 1.7.4.2 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 maintLibravatar Junio C Hamano1-2/+4
* jh/push-default-upstream-configname: push.default: Rename 'tracking' to 'upstream'
2011-03-16standardize brace placement in struct definitionsLibravatar Jonathan Nieder1-2/+1
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 <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-15config: drop support for GIT_CONFIG_NOGLOBALLibravatar Jonathan Nieder1-6/+1
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 <peff@peff.net> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-11Make the default abbrev length configurableLibravatar Linus Torvalds1-0/+8
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 <gitster@pobox.com>
2011-03-10Merge branch 'maint'Libravatar Junio C Hamano1-7/+0
* maint: Revert "core.abbrevguard: Ensure short object names stay unique a bit longer"