git/path.c, branch v1.8.2.2

longest_ancestor_length(): require prefix list entries to be normalized

2012-10-29T06:34:58Z

Move the responsibility for normalizing prefixes from longest_ancestor_length() to its callers. Use slightly different normalizations at the two callers: In setup_git_directory_gently_1(), use the old normalization, which ignores paths that are not usable. In the next commit we will change this caller to also resolve symlinks in the paths from GIT_CEILING_DIRECTORIES as part of the normalization. In "test-path-utils longest_ancestor_length", use the old normalization, but die() if any paths are unusable. Also change t0060 to only pass normalized paths to the test program (no empty entries or non-absolute paths, strip trailing slashes from the paths, and remove tests that thereby become redundant). The point of this change is to reduce the scope of the ancestor_length tests in t0060 from testing normalization+longest_prefix to testing only mostly longest_prefix. This is necessary because when setup_git_directory_gently_1() starts resolving symlinks as part of its normalization, it will not be reasonable to do the same in the test suite, because that would make the test results depend on the contents of the root directory of the filesystem on which the test is run. HOWEVER: under Windows, bash mangles arguments that look like absolute POSIX paths into DOS paths. So we have to retain the level of normalization done by normalize_path_copy() to convert the bash-mangled DOS paths (which contain backslashes) into paths that use forward slashes. Signed-off-by: Michael Haggerty Signed-off-by: Jeff King

longest_ancestor_length(): take a string_list argument for prefixes

2012-10-29T06:34:58Z

Change longest_ancestor_length() to take the prefixes argument as a string_list rather than as a colon-separated string. This will make it easier for the caller to alter the entries before calling longest_ancestor_length(). Signed-off-by: Michael Haggerty Signed-off-by: Jeff King

longest_ancestor_length(): use string_list_split()

2012-10-29T06:34:58Z

Signed-off-by: Michael Haggerty Signed-off-by: Jeff King

path.c: Use vsnpath() in the implementation of git_path()

2012-09-04T20:34:46Z

The current implementation of git_path() is essentially the same as that of vsnpath(), with two minor differences. First, git_path() currently insists that the git directory path is no longer than PATH_MAX-100 characters in length. However, vsnpath() does not attempt this arbitrary 100 character reservation for the remaining path components. Second, vsnpath() uses the "is_dir_sep()" macro, rather than comparing directly to '/', to determine if the git_dir path component ends with a path separator. In order to benefit from the above improvements, along with increased compatability with git_snpath() and git_pathdup(), we reimplement the git_path() function using vsnpath(). Signed-off-by: Ramsay Jones Signed-off-by: Junio C Hamano

path.c: Don't discard the return value of vsnpath()

2012-09-04T20:34:46Z

The git_snpath() and git_pathdup() functions both use the (static) function vsnpath() in their implementation. Also, they both discard the return value of vsnpath(), which has the effect of ignoring the side effect of calling cleanup_path() in the non-error return path. In order to ensure that the required cleanup happens, we use the pointer returned by vsnpath(), rather than the buffer passed into vsnpath(), to derive the return value from git_snpath() and git_pathdup(). Signed-off-by: Ramsay Jones Signed-off-by: Junio C Hamano

path.c: Remove the 'git_' prefix from a file scope function

2012-09-04T20:34:46Z

In particular, the git_vsnpath() function, despite the 'git_' prefix suggesting otherwise, is (correctly) declared with file scope. Signed-off-by: Ramsay Jones Signed-off-by: Junio C Hamano

config: read (but not write) from $XDG_CONFIG_HOME/git/config file

2012-06-25T16:05:55Z

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 Signed-off-by: Valentin Duperray Signed-off-by: Franck Jonas Signed-off-by: Lucien Kong Signed-off-by: Thomas Nguy Signed-off-by: Matthieu Moy Signed-off-by: Junio C Hamano

standardize and improve lookup rules for external local repos

2012-02-03T00:41:55Z

When you specify a local repository on the command line of clone, ls-remote, upload-pack, receive-pack, or upload-archive, or in a request to git-daemon, we perform a little bit of lookup magic, doing things like looking in working trees for .git directories and appending ".git" for bare repos. For clone, this magic happens in get_repo_path. For everything else, it happens in enter_repo. In both cases, there are some ambiguous or confusing cases that aren't handled well, and there is one case that is not handled the same by both methods. This patch tries to provide (and test!) standard, sensible lookup rules for both code paths. The intended changes are: 1. When looking up "foo", we have always preferred a working tree "foo" (containing "foo/.git" over the bare "foo.git". But we did not prefer a bare "foo" over "foo.git". With this patch, we do so. 2. We would select directories that existed but didn't actually look like git repositories. With this patch, we make sure a selected directory looks like a git repo. Not only is this more sensible in general, but it will help anybody who is negatively affected by change (1) negatively (e.g., if they had "foo.git" next to its separate work tree "foo", and expect to keep finding "foo.git" when they reference "foo"). 3. The enter_repo code path would, given "foo", look for "foo.git/.git" (i.e., do the ".git" append magic even for a repo with working tree). The clone code path did not; with this patch, they now behave the same. In the unlikely case of a working tree overlaying a bare repo (i.e., a ".git" directory _inside_ a bare repo), we continue to treat it as a working tree (prefering the "inner" .git over the bare repo). This is mainly because the combination seems nonsensical, and I'd rather stick with existing behavior on the off chance that somebody is relying on it. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

Learn to handle gitfiles in enter_repo

2011-10-04T20:30:38Z

The enter_repo() function is used to navigate into a .git directory. It knows how to find standard alternatives (DWIM) but it doesn't handle gitfiles created by git init --separate-git-dir. This means that git-fetch and others do not work with repositories using the separate-git-dir mechanism. Teach enter_repo() to deal with the gitfile mechanism by resolving the path to the redirected path and continuing tests on that path instead of the found file. Signed-off-by: Phil Hord Signed-off-by: Junio C Hamano

enter_repo: do not modify input

2011-10-04T20:30:38Z

entr_repo(..., 0) currently modifies the input to strip away trailing slashes. This means that we some times need to copy the input to keep the original. Change it to unconditionally copy it into the used_path buffer so we can safely use the input without having to copy it. Also store a working copy in validated_path up-front before we start resolving anything. Signed-off-by: Erik Faye-Lund Signed-off-by: Phil Hord Signed-off-by: Junio C Hamano