summaryrefslogtreecommitdiff
path: root/config.c
AgeCommit message (Collapse)AuthorFilesLines
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-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-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-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"
2011-03-10Revert "core.abbrevguard: Ensure short object names stay unique a bit longer"Libravatar Junio C Hamano1-7/+0
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 <gitster@pobox.com>
2011-02-27Merge branch 'jh/push-default-upstream-configname'Libravatar Junio C Hamano1-2/+4
* jh/push-default-upstream-configname: push.default: Rename 'tracking' to 'upstream'
2011-02-22Disallow empty section and variable namesLibravatar Libor Pechacek1-1/+6
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 <lpechacek@suse.cz> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-02-22Sanity-check config variable namesLibravatar Libor Pechacek1-39/+67
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 <lpechacek@suse.cz> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-02-16push.default: Rename 'tracking' to 'upstream'Libravatar Johan Herland1-2/+4
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 branch.foo.remote and branch.foo.merge 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 <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-12-28Merge branch 'nd/setup'Libravatar Junio C Hamano1-5/+14
* 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()Libravatar Nguyễn Thái Ngọc Duy1-5/+14
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 <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-12-21Merge branch 'jk/maint-decorate-01-bool'Libravatar Junio C Hamano1-5/+3
* jk/maint-decorate-01-bool: handle arbitrary ints in git_config_maybe_bool
2010-12-19handle arbitrary ints in git_config_maybe_boolLibravatar Jeff King1-5/+3
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 <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-12-08Merge branch 'jk/maint-decorate-01-bool'Libravatar Junio C Hamano1-2/+14
* jk/maint-decorate-01-bool: log.decorate: accept 0/1 bool values
2010-12-03Merge branch 'jc/abbrev-guard'Libravatar Junio C Hamano1-0/+7
* jc/abbrev-guard: core.abbrevguard: Ensure short object names stay unique a bit longer
2010-11-17log.decorate: accept 0/1 bool valuesLibravatar Jeff King1-2/+14
We explicitly document "0" and "1" as synonyms for "false" and "true" in boolean config options. However, we don't actually handle those values in git_config_maybe_bool. In most cases this works fine, as we call git_config_bool, which in turn calls git_config_bool_or_int, which in turn calls git_config_maybe_bool. Values of 0/1 are considered "not bool", but their integer values end up being converted to the corresponding boolean values. However, the log.decorate code looks for maybe_bool explicitly, so that it can fall back to the "short" and "full" strings. It does not handle 0/1 at all, and considers them invalid values. We cannot simply add 0/1 support to git_config_maybe_bool. That would confuse git_config_bool_or_int, which may want to distinguish the integer values "0" and "1" from bools. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-10-28core.abbrevguard: Ensure short object names stay unique a bit longerLibravatar Junio C Hamano1-0/+7
Even though git makes sure that it uses enough hexdigits to show an abbreviated object name unambiguously, as more objects are added to the repository over time, a short name that used to be unique will stop being unique. Git uses this many extra hexdigits that are more than necessary to make the object name currently unique, in the hope that its output will stay unique a bit longer. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-10-21config: treat non-existent config files as emptyLibravatar Jeff King1-3/+1
The git_config() function signals error by returning -1 in two instances: 1. An actual error occurs in opening a config file (parse errors cause an immediate die). 2. Of the three possible config files, none was found. However, this second case is often not an error at all; it simply means that the user has no configuration (they are outside a repo, and they have no ~/.gitconfig file). This can lead to confusing errors, such as when the bash completion calls "git config --list" outside of a repo. If the user has a ~/.gitconfig, the command completes succesfully; if they do not, it complains to stderr. This patch allows callers of git_config to distinguish between the two cases. Error is signaled by -1, and otherwise the return value is the number of files parsed. This means that the traditional "git_config(...) < 0" check for error should work, but callers who want to know whether we parsed any files or not can still do so. [jc: with tests from Jonathan] Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-08Merge branch 'kf/askpass-config'Libravatar Junio C Hamano1-0/+3
* kf/askpass-config: Extend documentation of core.askpass and GIT_ASKPASS. Allow core.askpass to override SSH_ASKPASS. Add a new option 'core.askpass'.
2010-08-31Add a new option 'core.askpass'.Libravatar Anselm Kruis1-0/+3
Setting this option has the same effect as setting the environment variable 'GIT_ASKPASS'. Signed-off-by: Knut Franke <k.franke@science-computing.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-24pass "git -c foo=bar" params through environmentLibravatar Jeff King1-3/+54
Git uses the "-c foo=bar" parameters to set a config variable for a single git invocation. We currently do this by making a list in the current process and consulting that list in git_config. This works fine for built-ins, but the config changes are silently ignored by subprocesses, including dashed externals and invocations to "git config" from shell scripts. This patch instead puts them in an environment variable which we consult when looking at config (both internally and via calls "git config"). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-21Merge branch 'eb/core-eol'Libravatar Junio C Hamano1-1/+17
* eb/core-eol: Add "core.eol" config variable Rename the "crlf" attribute "text" Add per-repository eol normalization Add tests for per-repository eol normalization Conflicts: Documentation/config.txt Makefile
2010-06-06Add "core.eol" config variableLibravatar Eyvind Bernhardsen1-0/+16
Introduce a new configuration variable, "core.eol", that allows the user to set which line endings to use for end-of-line-normalized files in the working directory. It defaults to "native", which means CRLF on Windows and LF everywhere else. Note that "core.autocrlf" overrides core.eol. This means that [core] autocrlf = true puts CRLFs in the working directory even if core.eol is set to "lf". Signed-off-by: Eyvind Bernhardsen <eyvind.bernhardsen@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-05-21Merge branch 'ld/discovery-limit-to-fs' (early part)Libravatar Junio C Hamano1-1/+1
* 'ld/discovery-limit-to-fs' (early part): Rename ONE_FILESYSTEM to DISCOVERY_ACROSS_FILESYSTEM GIT_ONE_FILESYSTEM: flip the default to stop at filesystem boundaries Add support for GIT_ONE_FILESYSTEM truncate cwd string before printing error message config.c: remove static keyword from git_env_bool()
2010-05-21Merge branch 'ar/config-from-command-line'Libravatar Junio C Hamano1-0/+58
* ar/config-from-command-line: Complete prototype of git_config_from_parameters() Use strbufs instead of open-coded string manipulation Allow passing of configuration parameters in the command line
2010-05-19Add per-repository eol normalizationLibravatar Eyvind Bernhardsen1-1/+1
Change the semantics of the "crlf" attribute so that it enables end-of-line normalization when it is set, regardless of "core.autocrlf". Add a new setting for "crlf": "auto", which enables end-of-line conversion but does not override the automatic text file detection. Add a new attribute "eol" with possible values "crlf" and "lf". When set, this attribute enables normalization and forces git to use CRLF or LF line endings in the working directory, respectively. The line ending style to be used for normalized text files in the working directory is set using "core.autocrlf". When it is set to "true", CRLFs are used in the working directory; when set to "input" or "false", LFs are used. Signed-off-by: Eyvind Bernhardsen <eyvind.bernhardsen@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-28Use strbufs instead of open-coded string manipulationLibravatar Alex Riesen1-32/+19
Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-28Allow passing of configuration parameters in the command lineLibravatar Alex Riesen1-0/+71
The values passed this way will override whatever is defined in the config files. Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-28config.c: remove static keyword from git_env_bool()Libravatar Lars R. Damerow1-1/+1
Since this function is the preferred way to handle boolean environment variables it's useful to have it available to other files. Signed-off-by: Lars R. Damerow <lars@pixar.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-17git_config_maybe_bool()Libravatar Junio C Hamano1-4/+17
Some configuration variables can take boolean values in addition to enumeration specific to them. Introduce git_config_maybe_bool() that returns 0 or 1 if the given value is boolean, or -1 if not, so that a parser for such a variable can check for boolean first and then parse other kinds of values as a fallback. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-20Merge branch 'jc/ident'Libravatar Junio C Hamano1-4/+2
* jc/ident: ident.c: replace fprintf with fputs to suppress compiler warning user_ident_sufficiently_given(): refactor the logic to be usable from elsewhere ident.c: treat $EMAIL as giving user.email identity explicitly ident.c: check explicit identity for name and email separately ident.c: remove unused variables
2010-01-13Merge branch 'nd/sparse'Libravatar Junio C Hamano1-0/+5
* nd/sparse: (25 commits) t7002: test for not using external grep on skip-worktree paths t7002: set test prerequisite "external-grep" if supported grep: do not do external grep on skip-worktree entries commit: correctly respect skip-worktree bit ie_match_stat(): do not ignore skip-worktree bit with CE_MATCH_IGNORE_VALID tests: rename duplicate t1009 sparse checkout: inhibit empty worktree Add tests for sparse checkout read-tree: add --no-sparse-checkout to disable sparse checkout support unpack-trees(): ignore worktree check outside checkout area unpack_trees(): apply $GIT_DIR/info/sparse-checkout to the final index unpack-trees(): "enable" sparse checkout and load $GIT_DIR/info/sparse-checkout unpack-trees.c: generalize verify_* functions unpack-trees(): add CE_WT_REMOVE to remove on worktree alone Introduce "sparse checkout" dir.c: export excluded_1() and add_excludes_from_file_1() excluded_1(): support exclude files in index unpack-trees(): carry skip-worktree bit over in merged_entry() Read .gitignore from index if it is skip-worktree Avoid writing to buffer in add_excludes_from_file_1() ... Conflicts: .gitignore Documentation/config.txt Documentation/git-update-index.txt Makefile entry.c t/t7002-grep.sh
2010-01-10ident.c: check explicit identity for name and email separatelyLibravatar Junio C Hamano1-4/+2
bb1ae3f (commit: Show committer if automatic, 2008-05-04) added a logic to check both name and email were given explicitly by the end user, but it assumed that fmt_ident() is never called before git_default_user_config() is called, which was fragile. The former calls setup_ident() and fills the "default" name and email, so the check in the config parser would have mistakenly said both are given even if only user.name was provided. Make the logic more robust by keeping track of name and email separately. Signed-off-by: Junio C Hamano <gitster@pobox.com> Acked-by: Santi Béjar <santi@agolina.net>
2009-11-22Merge branch 'mm/config-pathname-tilde-expand'Libravatar Junio C Hamano1-1/+11
* mm/config-pathname-tilde-expand: Documentation: avoid xmlto input error expand_user_path: expand ~ to $HOME, not to the actual homedir. Expand ~ and ~user in core.excludesfile, commit.template
2009-11-17Expand ~ and ~user in core.excludesfile, commit.templateLibravatar Matthieu Moy1-1/+11
These config variables are parsed to substitute ~ and ~user with getpw entries. user_path() refactored into new function expand_user_path(), to allow dynamically allocating the return buffer. Original patch by Karl Chen, modified by Matthieu Moy, and further amended by Junio C Hamano. Signed-off-by: Karl Chen <quarl@quarl.org> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-10-19Introduce commit notesLibravatar Johannes Schindelin1-0/+5
Commit notes are blobs which are shown together with the commit message. These blobs are taken from the notes ref, which you can configure by the config variable core.notesRef, which in turn can be overridden by the environment variable GIT_NOTES_REF. The notes ref is a branch which contains "files" whose names are the names of the corresponding commits (i.e. the SHA-1). The rationale for putting this information into a ref is this: we want to be able to fetch and possibly union-merge the notes, maybe even look at the date when a note was introduced, and we want to store them efficiently together with the other objects. This patch has been improved by the following contributions: - Thomas Rast: fix core.notesRef documentation - Tor Arne Vestbø: fix printing of multi-line notes - Alex Riesen: Using char array instead of char pointer costs less BSS - Johan Herland: Plug leak when msg is good, but msglen or type causes return Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Tor Arne Vestbø <tavestbo@trolltech.com> Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> get_commit_notes(): Plug memory leak when 'if' triggers, but not because of read_sha1_file() failure
2009-09-13Merge branch 'jk/unwanted-advices'Libravatar Junio C Hamano1-0/+3
* jk/unwanted-advices: status: make "how to stage" messages optional push: make non-fast-forward help message configurable
2009-09-13use write_str_in_full helper to avoid literal string lengthsLibravatar Jim Meyering1-1/+1
In 2d14d65 (Use a clearer style to issue commands to remote helpers, 2009-09-03) I happened to notice two changes like this: - write_in_full(helper->in, "list\n", 5); + + strbuf_addstr(&buf, "list\n"); + write_in_full(helper->in, buf.buf, buf.len); + strbuf_reset(&buf); IMHO, it would be better to define a new function, static inline ssize_t write_str_in_full(int fd, const char *str) { return write_in_full(fd, str, strlen(str)); } and then use it like this: - strbuf_addstr(&buf, "list\n"); - write_in_full(helper->in, buf.buf, buf.len); - strbuf_reset(&buf); + write_str_in_full(helper->in, "list\n"); Thus not requiring the added allocation, and still avoiding the maintenance risk of literal string lengths. These days, compilers are good enough that strlen("literal") imposes no run-time cost. Transformed via this: perl -pi -e \ 's/write_in_full\((.*?), (".*?"), \d+\)/write_str_in_full($1, $2)/'\ $(git grep -l 'write_in_full.*"') Signed-off-by: Jim Meyering <meyering@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-11push: make non-fast-forward help message configurableLibravatar Jeff King1-0/+3
This message is designed to help new users understand what has happened when refs fail to push. However, it does not help experienced users at all, and significantly clutters the output, frequently dwarfing the regular status table and making it harder to see. This patch introduces a general configuration mechanism for optional messages, with this push message as the first example. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>