git/setup.c, branch v1.8.2.2

Merge branch 'jk/alias-in-bare' into maint

2013-04-03T16:25:41Z

An aliased command spawned from a bare repository that does not say it is bare with "core.bare = yes" is treated as non-bare by mistake. * jk/alias-in-bare: setup: suppress implicit "." work-tree for bare repos environment: add GIT_PREFIX to local_repo_env cache.h: drop LOCAL_REPO_ENV_SIZE

Merge branch 'lf/setup-prefix-pathspec' into maint

2013-04-03T16:24:19Z

"git cmd -- ':(top'" was not diagnosed as an invalid syntax, and instead the parser kept reading beyond the end of the string. * lf/setup-prefix-pathspec: setup.c: check that the pathspec magic ends with ")" setup.c: stop prefix_pathspec() from looping past the end of string

setup.c: check that the pathspec magic ends with ")"

2013-03-14T16:39:36Z

The previous code did not diagnose an incorrectly spelled ":(top" as an error. Signed-off-by: Andrew Wong Signed-off-by: Junio C Hamano

setup.c: stop prefix_pathspec() from looping past the end of string

2013-03-14T16:39:09Z

The code assumes that the string ends at either `)` or `,`, and does not handle the case where strcspn() returns length due to end of string. So specifying ":(top" as pathspec will cause the loop to go past the end of string. Signed-off-by: Andrew Wong Signed-off-by: Junio C Hamano

setup: suppress implicit "." work-tree for bare repos

2013-03-08T22:02:40Z

If an explicit GIT_DIR is given without a working tree, we implicitly assume that the current working directory should be used as the working tree. E.g.,: GIT_DIR=/some/repo.git git status would compare against the cwd. Unfortunately, we fool this rule for sub-invocations of git by setting GIT_DIR internally ourselves. For example: git init foo cd foo/.git git status ;# fails, as we expect git config alias.st status git status ;# does not fail, but should What happens is that we run setup_git_directory when doing alias lookup (since we need to see the config), set GIT_DIR as a result, and then leave GIT_WORK_TREE blank (because we do not have one). Then when we actually run the status command, we do setup_git_directory again, which sees our explicit GIT_DIR and uses the cwd as an implicit worktree. It's tempting to argue that we should be suppressing that second invocation of setup_git_directory, as it could use the values we already found in memory. However, the problem still exists for sub-processes (e.g., if "git status" were an external command). You can see another example with the "--bare" option, which sets GIT_DIR explicitly. For example: git init foo cd foo/.git git status ;# fails git --bare status ;# does NOT fail We need some way of telling sub-processes "even though GIT_DIR is set, do not use cwd as an implicit working tree". We could do it by putting a special token into GIT_WORK_TREE, but the obvious choice (an empty string) has some portability problems. Instead, we add a new boolean variable, GIT_IMPLICIT_WORK_TREE, which suppresses the use of cwd as a working tree when GIT_DIR is set. We trigger the new variable when we know we are in a bare setting. The variable is left intentionally undocumented, as this is an internal detail (for now, anyway). If somebody comes up with a good alternate use for it, and once we are confident we have shaken any bugs out of it, we can consider promoting it further. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

environment: add GIT_PREFIX to local_repo_env

2013-03-08T22:02:31Z

The GIT_PREFIX variable is set based on our location within the working tree. It should therefore be cleared whenever GIT_WORK_TREE is cleared. In practice, this doesn't cause any bugs, because none of the sub-programs we invoke with local_repo_env cleared actually care about GIT_PREFIX. But this is the right thing to do, and future proofs us against that assumption changing. While we're at it, let's define a GIT_PREFIX_ENVIRONMENT macro; this avoids repetition of the string literal, which can help catch any spelling mistakes in the code. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

Merge branch 'mh/maint-ceil-absolute'

2013-02-27T17:47:28Z

An earlier workaround designed to help people who list logical directories that will not match what getcwd(3) returns in the GIT_CEILING_DIRECTORIES had an adverse effect when it is slow to stat and readlink a directory component of an element listed on it. * mh/maint-ceil-absolute: Provide a mechanism to turn off symlink resolution in ceiling paths

Provide a mechanism to turn off symlink resolution in ceiling paths

2013-02-22T19:37:34Z

Commit 1b77d83cab 'setup_git_directory_gently_1(): resolve symlinks in ceiling paths' changed the setup code to resolve symlinks in the entries in GIT_CEILING_DIRECTORIES. Because those entries are compared textually to the symlink-resolved current directory, an entry in GIT_CEILING_DIRECTORIES that contained a symlink would have no effect. It was known that this could cause performance problems if the symlink resolution *itself* touched slow filesystems, but it was thought that such use cases would be unlikely. The intention of the earlier change was to deal with a case when the user has this: GIT_CEILING_DIRECTORIES=/home/gitster but in reality, /home/gitster is a symbolic link to somewhere else, e.g. /net/machine/home4/gitster. A textual comparison between the specified value /home/gitster and the location getcwd(3) returns would not help us, but readlink("/home/gitster") would still be fast. After this change was released, Anders Kaseorg reported: > [...] my computer has been acting so slow when I’m not connected to > the network. I put various network filesystem paths in > $GIT_CEILING_DIRECTORIES, such as > /afs/athena.mit.edu/user/a/n/andersk (to avoid hitting its parents > /afs/athena.mit.edu, /afs/athena.mit.edu/user/a, and > /afs/athena.mit.edu/user/a/n which all live in different AFS > volumes). Now when I’m not connected to the network, every > invocation of Git, including the __git_ps1 in my shell prompt, waits > for AFS to timeout. To allow users to work around this problem, give them a mechanism to turn off symlink resolution in GIT_CEILING_DIRECTORIES entries. All the entries that follow an empty entry will not be checked for symbolic links and used literally in comparison. E.g. with these: GIT_CEILING_DIRECTORIES=:/foo/bar:/xyzzy or GIT_CEILING_DIRECTORIES=/foo/bar::/xyzzy we will not readlink("/xyzzy") because it comes after an empty entry. With the former (but not with the latter), "/foo/bar" comes after an empty entry, and we will not readlink it, either. Signed-off-by: Michael Haggerty Signed-off-by: Junio C Hamano

Merge branch 'nd/magic-pathspec-from-root'

2013-01-30T16:52:53Z

When giving arguments without "--" disambiguation, object names that come earlier on the command line must not be interpretable as pathspecs and pathspecs that come later on the command line must not be interpretable as object names. Tweak the disambiguation rule so that ":/" (no other string before or after) is always interpreted as a pathspec, to avoid having to say "git cmd -- :/". * nd/magic-pathspec-from-root: grep: avoid accepting ambiguous revision Update :/abc ambiguity check

Merge branch 'as/check-ignore'

2013-01-24T05:19:10Z

Add a new command "git check-ignore" for debugging .gitignore files. The variable names may want to get cleaned up but that can be done in-tree. * as/check-ignore: clean.c, ls-files.c: respect encapsulation of exclude_list_groups t0008: avoid brace expansion add git-check-ignore sub-command setup.c: document get_pathspec() add.c: extract new die_if_path_beyond_symlink() for reuse add.c: extract check_path_for_gitlink() from treat_gitlinks() for reuse pathspec.c: rename newly public functions for clarity add.c: move pathspec matchers into new pathspec.c for reuse add.c: remove unused argument from validate_pathspec() dir.c: improve docs for match_pathspec() and match_pathspec_depth() dir.c: provide clear_directory() for reclaiming dir_struct memory dir.c: keep track of where patterns came from dir.c: use a single struct exclude_list per source of excludes Conflicts: builtin/ls-files.c dir.c