user/sven/git.git/path.c, branch v1.8.0.2

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

read_gitfile_gently(): rename misnamed function to read_gitfile()

2011-08-22T21:04:56Z

The function was not gentle at all to the callers and died without giving them a chance to deal with possible errors. Rename it to read_gitfile(), and update all the callers. As no existing caller needs a true "gently" variant, we do not bother adding one at this point. Signed-off-by: Junio C Hamano

Name make_*_path functions more accurately

2011-03-17T23:08:30Z

Rename the make_*_path functions so it's clearer what they do, in particlar make clear what the differnce between make_absolute_path and make_nonrelative_path is by renaming them real_path and absolute_path respectively. make_relative_path has an understandable name and is renamed to relative_path to maintain the name convention. The function calls have been replaced 1-to-1 in their usage. Signed-off-by: Carlos Martín Nieto Signed-off-by: Junio C Hamano

path helpers: move git_mkstemp* to wrapper.c

2010-11-10T19:04:26Z

git_mkstemp_mode and related functions do not require access to specialized git machinery, unlike some other functions from path.c (like set_shared_perm()). Move them to wrapper.c where the wrapper xmkstemp_mode is defined. This eliminates a dependency of wrapper.o on environment.o via path.o. With typical linkers (e.g., gcc), that dependency makes programs that use functions from wrapper.o and not environment.o or path.o larger than they need to be. Signed-off-by: Jonathan Nieder Signed-off-by: Junio C Hamano