git/setup.c, branch v2.4.9

setup_git_directory: delay core.bare/core.worktree errors

2015-05-29T16:27:27Z

If both core.bare and core.worktree are set, we complain about the bogus config and die. Dying is good, because it avoids commands running and doing damage in a potentially incorrect setup. But dying _there_ is bad, because it means that commands which do not even care about the work tree cannot run. This can make repairing the situation harder: [setup] $ git config core.bare true $ git config core.worktree /some/path [OK, expected.] $ git status fatal: core.bare and core.worktree do not make sense [Hrm...] $ git config --unset core.worktree fatal: core.bare and core.worktree do not make sense [Nope...] $ git config --edit fatal: core.bare and core.worktree do not make sense [Gaaah.] $ git help config fatal: core.bare and core.worktree do not make sense Instead, let's issue a warning about the bogus config when we notice it (i.e., for all commands), but only die when the command tries to use the work tree (by calling setup_work_tree). So we now get: $ git status warning: core.bare and core.worktree do not make sense fatal: unable to set up work tree using invalid config $ git config --unset core.worktree warning: core.bare and core.worktree do not make sense We have to update t1510 to accomodate this; it uses symbolic-ref to check whether the configuration works or not, but of course that command does not use the working tree. Instead, we switch it to use `git status`, as it requires a work-tree, does not need any special setup, and is read-only (so a failure will not adversely affect further tests). In addition, we add a new test that checks the desired behavior (i.e., that running "git config" with the bogus config does in fact work). Reported-by: SZEDER Gábor Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

Merge branch 'rs/strbuf-getcwd'

2014-09-02T20:28:44Z

Reduce the use of fixed sized buffer passed to getcwd() calls by introducing xgetcwd() helper. * rs/strbuf-getcwd: use strbuf_add_absolute_path() to add absolute paths abspath: convert absolute_path() to strbuf use xgetcwd() to set $GIT_DIR use xgetcwd() to get the current directory or die wrapper: add xgetcwd() abspath: convert real_path_internal() to strbuf abspath: use strbuf_getcwd() to remember original working directory setup: convert setup_git_directory_gently_1 et al. to strbuf unix-sockets: use strbuf_getcwd() strbuf: add strbuf_getcwd()

use xgetcwd() to get the current directory or die

2014-08-26T18:06:06Z

Convert several calls of getcwd() and die() to use xgetcwd() instead. This way we get rid of fixed-size buffers (which can be too small depending on the used file system) and gain consistent error messages. Signed-off-by: Rene Scharfe Signed-off-by: Junio C Hamano

setup: convert setup_git_directory_gently_1 et al. to strbuf

2014-08-26T18:06:04Z

Convert setup_git_directory_gently_1() and its helper functions setup_explicit_git_dir(), setup_discovered_git_dir() and setup_bare_git_dir() to use a struct strbuf to hold the current working directory. Replacing the PATH_MAX-sized buffer used before removes a path length limition on some file systems. The functions are converted all in one go because they all read and write the variable cwd. Signed-off-by: Rene Scharfe Signed-off-by: Junio C Hamano

add `config_set` API for caching config-like files

2014-07-29T21:29:56Z

Currently `git_config()` uses a callback mechanism and file rereads for config values. Due to this approach, it is not uncommon for the config files to be parsed several times during the run of a git program, with different callbacks picking out different variables useful to themselves. Add a `config_set`, that can be used to construct an in-memory cache for config-like files that the caller specifies (i.e., files like `.gitmodules`, `~/.gitconfig` etc.). Add two external functions `git_configset_get_value` and `git_configset_get_value_multi` for querying from the config sets. `git_configset_get_value` follows `last one wins` semantic (i.e. if there are multiple matches for the queried key in the files of the configset the value returned will be the last entry in `value_list`). `git_configset_get_value_multi` returns a list of values sorted in order of increasing priority (i.e. last match will be at the end of the list). Add type specific query functions like `git_configset_get_bool` and similar. Add a default `config_set`, `the_config_set` to cache all key-value pairs read from usual config files (repo specific .git/config, user wide ~/.gitconfig, XDG config and the global /etc/gitconfig). `the_config_set` is populated using `git_config()`. Add two external functions `git_config_get_value` and `git_config_get_value_multi` for querying in a non-callback manner from `the_config_set`. Also, add type specific query functions that are implemented as a thin wrapper around the `config_set` API. Signed-off-by: Matthieu Moy Signed-off-by: Tanay Abhra Signed-off-by: Junio C Hamano

Merge branch 'mw/symlinks'

2014-05-02T20:11:03Z

A finishing touch fix to a new change already in 'master'. * mw/symlinks: setup: fix windows path buffer over-stepping

setup: fix windows path buffer over-stepping

2014-04-24T20:46:13Z

Fix a buffer over-stepping issue triggered by providing an absolute path that is similar to the work tree path. abspath_part_inside_repo() may currently increment the path pointer by offset_1st_component() + wtlen, which is too much, since offset_1st_component() is a subset of wtlen. For the *nix-style prefix '/', this does (by luck) not cause any issues, since offset_1st_component() is 1 and there will always be a '/' or '\0' that can "absorb" this. In the case of DOS-style prefixes though, the offset_1st_component() is 3 and this can potentially over-step the string buffer. For example if work_tree = "c:/r" path = "c:/rl" Then wtlen is 4, and incrementing the path pointer by (3 + 4) would end up 2 bytes outside a string buffer of length 6. Similarly if work_tree = "c:/r" path = "c:/rl/d/a" Then (since the loop starts by also incrementing the pointer one step), this would mean that the function would miss checking if "c:/rl/d" could be the work_tree, arguably this is unlikely though, since it would only be possible with symlinks on windows. Fix this by simply avoiding to increment by offset_1st_component() and wtlen at the same time. Signed-off-by: Martin Erik Werner Signed-off-by: Junio C Hamano

Merge branch 'nd/daemonize-gc'

2014-03-05T23:06:39Z

Allow running "gc --auto" in the background. * nd/daemonize-gc: gc: config option for running --auto in background daemon: move daemonize() to libgit.a

Merge branch 'mw/symlinks'

2014-02-27T22:01:37Z

All subcommands that take pathspecs mishandled an in-tree symbolic link when given it as a full path from the root (which arguably is a sick way to use pathspecs). "git ls-files -s $(pwd)/RelNotes" in our tree is an easy reproduction recipe. * mw/symlinks: setup: don't dereference in-tree symlinks for absolute paths setup: add abspath_part_inside_repo() function t0060: add tests for prefix_path when path begins with work tree t0060: add test for prefix_path when path == work tree t0060: add test for prefix_path on symlinks via absolute paths t3004: add test for ls-files on symlinks via absolute paths

daemon: move daemonize() to libgit.a

2014-02-10T18:46:35Z

Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano