git/setup.c, branch v1.7.9.7

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

Merge branch 'cb/common-prefix-unification'

2011-10-10T22:56:17Z

* cb/common-prefix-unification: rename pathspec_prefix() to common_prefix() and move to dir.[ch] consolidate pathspec_prefix and common_prefix remove prefix argument from pathspec_prefix

Merge branch 'fg/submodule-git-file-git-dir'

2011-10-10T22:56:17Z

* fg/submodule-git-file-git-dir: Move git-dir for submodules rev-parse: add option --resolve-git-dir Conflicts: cache.h git-submodule.sh

rename pathspec_prefix() to common_prefix() and move to dir.[ch]

2011-09-12T21:38:32Z

Also make common_prefix_len() static as this refactoring makes dir.c itself the only caller of this helper function. Signed-off-by: Clemens Buchacher Signed-off-by: Junio C Hamano

consolidate pathspec_prefix and common_prefix

2011-09-06T19:54:19Z

The implementation from pathspec_prefix (slightly modified) replaces the current common_prefix, because it also respects glob characters. Based on a patch by Clemens Buchacher. Signed-off-by: Junio C Hamano

remove prefix argument from pathspec_prefix

2011-09-06T19:50:10Z

Passing a prefix to a function that is supposed to find the prefix is strange. And it's really only used if the pathspec is NULL. Make the callers handle this case instead. As we are always returning a fresh copy of a string (or NULL), change the type of the returned value to non-const "char *". Signed-off-by: Clemens Buchacher Signed-off-by: Junio C Hamano

Merge branch 'nd/maint-clone-gitdir'

2011-08-29T04:20:28Z

* nd/maint-clone-gitdir: clone: allow to clone from .git file read_gitfile_gently(): rename misnamed function to read_gitfile()

Merge branch 'di/parse-options-split'

2011-08-25T23:00:20Z

* di/parse-options-split: Reduce parse-options.o dependencies parse-options: export opterr, optbug

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

rev-parse: add option --resolve-git-dir

2011-08-16T18:04:31Z

Check if is a valid git-dir or a valid git-file that points to a valid git-dir. We want tests to be independent from the fact that a git-dir may be a git-file. Thus we changed tests to use this feature. Signed-off-by: Fredrik Gustafsson Mentored-by: Jens Lehmann Mentored-by: Heiko Voigt Signed-off-by: Junio C Hamano