2005-08-17 03:06:34 +02:00
|
|
|
#include "cache.h"
|
Clean up work-tree handling
The old version of work-tree support was an unholy mess, barely readable,
and not to the point.
For example, why do you have to provide a worktree, when it is not used?
As in "git status". Now it works.
Another riddle was: if you can have work trees inside the git dir, why
are some programs complaining that they need a work tree?
IOW it is allowed to call
$ git --git-dir=../ --work-tree=. bla
when you really want to. In this case, you are both in the git directory
and in the working tree. So, programs have to actually test for the right
thing, namely if they are inside a working tree, and not if they are
inside a git directory.
Also, GIT_DIR=../.git should behave the same as if no GIT_DIR was
specified, unless there is a repository in the current working directory.
It does now.
The logic to determine if a repository is bare, or has a work tree
(tertium non datur), is this:
--work-tree=bla overrides GIT_WORK_TREE, which overrides core.bare = true,
which overrides core.worktree, which overrides GIT_DIR/.. when GIT_DIR
ends in /.git, which overrides the directory in which .git/ was found.
In related news, a long standing bug was fixed: when in .git/bla/x.git/,
which is a bare repository, git formerly assumed ../.. to be the
appropriate git dir. This problem was reported by Shawn Pearce to have
caused much pain, where a colleague mistakenly ran "git init" in "/" a
long time ago, and bare repositories just would not work.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-08-01 02:30:14 +02:00
|
|
|
#include "dir.h"
|
2012-10-28 17:16:24 +01:00
|
|
|
#include "string-list.h"
|
Clean up work-tree handling
The old version of work-tree support was an unholy mess, barely readable,
and not to the point.
For example, why do you have to provide a worktree, when it is not used?
As in "git status". Now it works.
Another riddle was: if you can have work trees inside the git dir, why
are some programs complaining that they need a work tree?
IOW it is allowed to call
$ git --git-dir=../ --work-tree=. bla
when you really want to. In this case, you are both in the git directory
and in the working tree. So, programs have to actually test for the right
thing, namely if they are inside a working tree, and not if they are
inside a git directory.
Also, GIT_DIR=../.git should behave the same as if no GIT_DIR was
specified, unless there is a repository in the current working directory.
It does now.
The logic to determine if a repository is bare, or has a work tree
(tertium non datur), is this:
--work-tree=bla overrides GIT_WORK_TREE, which overrides core.bare = true,
which overrides core.worktree, which overrides GIT_DIR/.. when GIT_DIR
ends in /.git, which overrides the directory in which .git/ was found.
In related news, a long standing bug was fixed: when in .git/bla/x.git/,
which is a bare repository, git formerly assumed ../.. to be the
appropriate git dir. This problem was reported by Shawn Pearce to have
caused much pain, where a colleague mistakenly ran "git init" in "/" a
long time ago, and bare repositories just would not work.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-08-01 02:30:14 +02:00
|
|
|
|
|
|
|
static int inside_git_dir = -1;
|
|
|
|
static int inside_work_tree = -1;
|
2005-08-17 03:06:34 +02:00
|
|
|
|
2012-06-21 20:09:50 +02:00
|
|
|
static char *prefix_path_gently(const char *prefix, int len, const char *path)
|
setup: sanitize absolute and funny paths in get_pathspec()
The prefix_path() function called from get_pathspec() is
responsible for translating list of user-supplied pathspecs to
list of pathspecs that is relative to the root of the work
tree. When working inside a subdirectory, the user-supplied
pathspecs are taken to be relative to the current subdirectory.
Among special path components in pathspecs, we used to accept
and interpret only "." ("the directory", meaning a no-op) and
".." ("up one level") at the beginning. Everything else was
passed through as-is.
For example, if you are in Documentation/ directory of the
project, you can name Documentation/howto/maintain-git.txt as:
howto/maintain-git.txt
../Documentation/howto/maitain-git.txt
../././Documentation/howto/maitain-git.txt
but not as:
howto/./maintain-git.txt
$(pwd)/howto/maintain-git.txt
This patch updates prefix_path() in several ways:
- If the pathspec is not absolute, prefix (i.e. the current
subdirectory relative to the root of the work tree, with
terminating slash, if not empty) and the pathspec is
concatenated first and used in the next step. Otherwise,
that absolute pathspec is used in the next step.
- Then special path components "." (no-op) and ".." (up one
level) are interpreted to simplify the path. It is an error
to have too many ".." to cause the intermediate result to
step outside of the input to this step.
- If the original pathspec was not absolute, the result from
the previous step is the resulting "sanitized" pathspec.
Otherwise, the result from the previous step is still
absolute, and it is an error if it does not begin with the
directory that corresponds to the root of the work tree. The
directory is stripped away from the result and is returned.
- In any case, the resulting pathspec in the array
get_pathspec() returns omit the ones that caused errors.
With this patch, the last two examples also behave as expected.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-01-29 07:44:27 +01:00
|
|
|
{
|
|
|
|
const char *orig = path;
|
2010-12-27 11:54:37 +01:00
|
|
|
char *sanitized;
|
|
|
|
if (is_absolute_path(orig)) {
|
2011-03-17 12:26:46 +01:00
|
|
|
const char *temp = real_path(path);
|
2010-12-27 11:54:37 +01:00
|
|
|
sanitized = xmalloc(len + strlen(temp) + 1);
|
|
|
|
strcpy(sanitized, temp);
|
|
|
|
} else {
|
|
|
|
sanitized = xmalloc(len + strlen(path) + 1);
|
setup: sanitize absolute and funny paths in get_pathspec()
The prefix_path() function called from get_pathspec() is
responsible for translating list of user-supplied pathspecs to
list of pathspecs that is relative to the root of the work
tree. When working inside a subdirectory, the user-supplied
pathspecs are taken to be relative to the current subdirectory.
Among special path components in pathspecs, we used to accept
and interpret only "." ("the directory", meaning a no-op) and
".." ("up one level") at the beginning. Everything else was
passed through as-is.
For example, if you are in Documentation/ directory of the
project, you can name Documentation/howto/maintain-git.txt as:
howto/maintain-git.txt
../Documentation/howto/maitain-git.txt
../././Documentation/howto/maitain-git.txt
but not as:
howto/./maintain-git.txt
$(pwd)/howto/maintain-git.txt
This patch updates prefix_path() in several ways:
- If the pathspec is not absolute, prefix (i.e. the current
subdirectory relative to the root of the work tree, with
terminating slash, if not empty) and the pathspec is
concatenated first and used in the next step. Otherwise,
that absolute pathspec is used in the next step.
- Then special path components "." (no-op) and ".." (up one
level) are interpreted to simplify the path. It is an error
to have too many ".." to cause the intermediate result to
step outside of the input to this step.
- If the original pathspec was not absolute, the result from
the previous step is the resulting "sanitized" pathspec.
Otherwise, the result from the previous step is still
absolute, and it is an error if it does not begin with the
directory that corresponds to the root of the work tree. The
directory is stripped away from the result and is returned.
- In any case, the resulting pathspec in the array
get_pathspec() returns omit the ones that caused errors.
With this patch, the last two examples also behave as expected.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-01-29 07:44:27 +01:00
|
|
|
if (len)
|
|
|
|
memcpy(sanitized, prefix, len);
|
|
|
|
strcpy(sanitized + len, path);
|
2005-08-17 05:44:32 +02:00
|
|
|
}
|
2009-02-07 16:08:28 +01:00
|
|
|
if (normalize_path_copy(sanitized, sanitized))
|
setup: sanitize absolute and funny paths in get_pathspec()
The prefix_path() function called from get_pathspec() is
responsible for translating list of user-supplied pathspecs to
list of pathspecs that is relative to the root of the work
tree. When working inside a subdirectory, the user-supplied
pathspecs are taken to be relative to the current subdirectory.
Among special path components in pathspecs, we used to accept
and interpret only "." ("the directory", meaning a no-op) and
".." ("up one level") at the beginning. Everything else was
passed through as-is.
For example, if you are in Documentation/ directory of the
project, you can name Documentation/howto/maintain-git.txt as:
howto/maintain-git.txt
../Documentation/howto/maitain-git.txt
../././Documentation/howto/maitain-git.txt
but not as:
howto/./maintain-git.txt
$(pwd)/howto/maintain-git.txt
This patch updates prefix_path() in several ways:
- If the pathspec is not absolute, prefix (i.e. the current
subdirectory relative to the root of the work tree, with
terminating slash, if not empty) and the pathspec is
concatenated first and used in the next step. Otherwise,
that absolute pathspec is used in the next step.
- Then special path components "." (no-op) and ".." (up one
level) are interpreted to simplify the path. It is an error
to have too many ".." to cause the intermediate result to
step outside of the input to this step.
- If the original pathspec was not absolute, the result from
the previous step is the resulting "sanitized" pathspec.
Otherwise, the result from the previous step is still
absolute, and it is an error if it does not begin with the
directory that corresponds to the root of the work tree. The
directory is stripped away from the result and is returned.
- In any case, the resulting pathspec in the array
get_pathspec() returns omit the ones that caused errors.
With this patch, the last two examples also behave as expected.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-01-29 07:44:27 +01:00
|
|
|
goto error_out;
|
2008-02-19 22:29:40 +01:00
|
|
|
if (is_absolute_path(orig)) {
|
2010-02-14 16:44:44 +01:00
|
|
|
size_t root_len, len, total;
|
setup: sanitize absolute and funny paths in get_pathspec()
The prefix_path() function called from get_pathspec() is
responsible for translating list of user-supplied pathspecs to
list of pathspecs that is relative to the root of the work
tree. When working inside a subdirectory, the user-supplied
pathspecs are taken to be relative to the current subdirectory.
Among special path components in pathspecs, we used to accept
and interpret only "." ("the directory", meaning a no-op) and
".." ("up one level") at the beginning. Everything else was
passed through as-is.
For example, if you are in Documentation/ directory of the
project, you can name Documentation/howto/maintain-git.txt as:
howto/maintain-git.txt
../Documentation/howto/maitain-git.txt
../././Documentation/howto/maitain-git.txt
but not as:
howto/./maintain-git.txt
$(pwd)/howto/maintain-git.txt
This patch updates prefix_path() in several ways:
- If the pathspec is not absolute, prefix (i.e. the current
subdirectory relative to the root of the work tree, with
terminating slash, if not empty) and the pathspec is
concatenated first and used in the next step. Otherwise,
that absolute pathspec is used in the next step.
- Then special path components "." (no-op) and ".." (up one
level) are interpreted to simplify the path. It is an error
to have too many ".." to cause the intermediate result to
step outside of the input to this step.
- If the original pathspec was not absolute, the result from
the previous step is the resulting "sanitized" pathspec.
Otherwise, the result from the previous step is still
absolute, and it is an error if it does not begin with the
directory that corresponds to the root of the work tree. The
directory is stripped away from the result and is returned.
- In any case, the resulting pathspec in the array
get_pathspec() returns omit the ones that caused errors.
With this patch, the last two examples also behave as expected.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-01-29 07:44:27 +01:00
|
|
|
const char *work_tree = get_git_work_tree();
|
2009-12-16 19:50:09 +01:00
|
|
|
if (!work_tree)
|
|
|
|
goto error_out;
|
|
|
|
len = strlen(work_tree);
|
2010-02-14 16:44:44 +01:00
|
|
|
root_len = offset_1st_component(work_tree);
|
2009-12-16 19:50:09 +01:00
|
|
|
total = strlen(sanitized) + 1;
|
setup: sanitize absolute and funny paths in get_pathspec()
The prefix_path() function called from get_pathspec() is
responsible for translating list of user-supplied pathspecs to
list of pathspecs that is relative to the root of the work
tree. When working inside a subdirectory, the user-supplied
pathspecs are taken to be relative to the current subdirectory.
Among special path components in pathspecs, we used to accept
and interpret only "." ("the directory", meaning a no-op) and
".." ("up one level") at the beginning. Everything else was
passed through as-is.
For example, if you are in Documentation/ directory of the
project, you can name Documentation/howto/maintain-git.txt as:
howto/maintain-git.txt
../Documentation/howto/maitain-git.txt
../././Documentation/howto/maitain-git.txt
but not as:
howto/./maintain-git.txt
$(pwd)/howto/maintain-git.txt
This patch updates prefix_path() in several ways:
- If the pathspec is not absolute, prefix (i.e. the current
subdirectory relative to the root of the work tree, with
terminating slash, if not empty) and the pathspec is
concatenated first and used in the next step. Otherwise,
that absolute pathspec is used in the next step.
- Then special path components "." (no-op) and ".." (up one
level) are interpreted to simplify the path. It is an error
to have too many ".." to cause the intermediate result to
step outside of the input to this step.
- If the original pathspec was not absolute, the result from
the previous step is the resulting "sanitized" pathspec.
Otherwise, the result from the previous step is still
absolute, and it is an error if it does not begin with the
directory that corresponds to the root of the work tree. The
directory is stripped away from the result and is returned.
- In any case, the resulting pathspec in the array
get_pathspec() returns omit the ones that caused errors.
With this patch, the last two examples also behave as expected.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-01-29 07:44:27 +01:00
|
|
|
if (strncmp(sanitized, work_tree, len) ||
|
2010-02-14 16:44:44 +01:00
|
|
|
(len > root_len && sanitized[len] != '\0' && sanitized[len] != '/')) {
|
setup: sanitize absolute and funny paths in get_pathspec()
The prefix_path() function called from get_pathspec() is
responsible for translating list of user-supplied pathspecs to
list of pathspecs that is relative to the root of the work
tree. When working inside a subdirectory, the user-supplied
pathspecs are taken to be relative to the current subdirectory.
Among special path components in pathspecs, we used to accept
and interpret only "." ("the directory", meaning a no-op) and
".." ("up one level") at the beginning. Everything else was
passed through as-is.
For example, if you are in Documentation/ directory of the
project, you can name Documentation/howto/maintain-git.txt as:
howto/maintain-git.txt
../Documentation/howto/maitain-git.txt
../././Documentation/howto/maitain-git.txt
but not as:
howto/./maintain-git.txt
$(pwd)/howto/maintain-git.txt
This patch updates prefix_path() in several ways:
- If the pathspec is not absolute, prefix (i.e. the current
subdirectory relative to the root of the work tree, with
terminating slash, if not empty) and the pathspec is
concatenated first and used in the next step. Otherwise,
that absolute pathspec is used in the next step.
- Then special path components "." (no-op) and ".." (up one
level) are interpreted to simplify the path. It is an error
to have too many ".." to cause the intermediate result to
step outside of the input to this step.
- If the original pathspec was not absolute, the result from
the previous step is the resulting "sanitized" pathspec.
Otherwise, the result from the previous step is still
absolute, and it is an error if it does not begin with the
directory that corresponds to the root of the work tree. The
directory is stripped away from the result and is returned.
- In any case, the resulting pathspec in the array
get_pathspec() returns omit the ones that caused errors.
With this patch, the last two examples also behave as expected.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-01-29 07:44:27 +01:00
|
|
|
error_out:
|
2012-06-21 20:09:50 +02:00
|
|
|
free(sanitized);
|
|
|
|
return NULL;
|
setup: sanitize absolute and funny paths in get_pathspec()
The prefix_path() function called from get_pathspec() is
responsible for translating list of user-supplied pathspecs to
list of pathspecs that is relative to the root of the work
tree. When working inside a subdirectory, the user-supplied
pathspecs are taken to be relative to the current subdirectory.
Among special path components in pathspecs, we used to accept
and interpret only "." ("the directory", meaning a no-op) and
".." ("up one level") at the beginning. Everything else was
passed through as-is.
For example, if you are in Documentation/ directory of the
project, you can name Documentation/howto/maintain-git.txt as:
howto/maintain-git.txt
../Documentation/howto/maitain-git.txt
../././Documentation/howto/maitain-git.txt
but not as:
howto/./maintain-git.txt
$(pwd)/howto/maintain-git.txt
This patch updates prefix_path() in several ways:
- If the pathspec is not absolute, prefix (i.e. the current
subdirectory relative to the root of the work tree, with
terminating slash, if not empty) and the pathspec is
concatenated first and used in the next step. Otherwise,
that absolute pathspec is used in the next step.
- Then special path components "." (no-op) and ".." (up one
level) are interpreted to simplify the path. It is an error
to have too many ".." to cause the intermediate result to
step outside of the input to this step.
- If the original pathspec was not absolute, the result from
the previous step is the resulting "sanitized" pathspec.
Otherwise, the result from the previous step is still
absolute, and it is an error if it does not begin with the
directory that corresponds to the root of the work tree. The
directory is stripped away from the result and is returned.
- In any case, the resulting pathspec in the array
get_pathspec() returns omit the ones that caused errors.
With this patch, the last two examples also behave as expected.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-01-29 07:44:27 +01:00
|
|
|
}
|
|
|
|
if (sanitized[len] == '/')
|
|
|
|
len++;
|
|
|
|
memmove(sanitized, sanitized + len, total - len);
|
|
|
|
}
|
|
|
|
return sanitized;
|
2005-08-17 05:44:32 +02:00
|
|
|
}
|
|
|
|
|
2012-06-21 20:09:50 +02:00
|
|
|
char *prefix_path(const char *prefix, int len, const char *path)
|
|
|
|
{
|
|
|
|
char *r = prefix_path_gently(prefix, len, path);
|
|
|
|
if (!r)
|
|
|
|
die("'%s' is outside repository", path);
|
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
|
|
|
int path_inside_repo(const char *prefix, const char *path)
|
|
|
|
{
|
|
|
|
int len = prefix ? strlen(prefix) : 0;
|
|
|
|
char *r = prefix_path_gently(prefix, len, path);
|
|
|
|
if (r) {
|
|
|
|
free(r);
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2009-10-18 09:27:24 +02:00
|
|
|
int check_filename(const char *prefix, const char *arg)
|
|
|
|
{
|
|
|
|
const char *name;
|
|
|
|
struct stat st;
|
|
|
|
|
2013-01-21 14:00:48 +01:00
|
|
|
if (!prefixcmp(arg, ":/")) {
|
|
|
|
if (arg[2] == '\0') /* ":/" is root dir, always exists */
|
|
|
|
return 1;
|
|
|
|
name = arg + 2;
|
|
|
|
} else if (prefix)
|
|
|
|
name = prefix_filename(prefix, strlen(prefix), arg);
|
|
|
|
else
|
|
|
|
name = arg;
|
2009-10-18 09:27:24 +02:00
|
|
|
if (!lstat(name, &st))
|
|
|
|
return 1; /* file exists */
|
|
|
|
if (errno == ENOENT || errno == ENOTDIR)
|
|
|
|
return 0; /* file does not exist */
|
|
|
|
die_errno("failed to stat '%s'", arg);
|
|
|
|
}
|
|
|
|
|
2012-06-18 20:18:21 +02:00
|
|
|
static void NORETURN die_verify_filename(const char *prefix,
|
|
|
|
const char *arg,
|
|
|
|
int diagnose_misspelt_rev)
|
2009-12-07 11:10:50 +01:00
|
|
|
{
|
2012-06-18 20:18:21 +02:00
|
|
|
if (!diagnose_misspelt_rev)
|
|
|
|
die("%s: no such path in the working tree.\n"
|
2012-08-03 10:21:20 +02:00
|
|
|
"Use 'git <command> -- <path>...' to specify paths that do not exist locally.",
|
2012-06-18 20:18:21 +02:00
|
|
|
arg);
|
2011-05-10 21:05:01 +02:00
|
|
|
/*
|
|
|
|
* Saying "'(icase)foo' does not exist in the index" when the
|
|
|
|
* user gave us ":(icase)foo" is just stupid. A magic pathspec
|
|
|
|
* begins with a colon and is followed by a non-alnum; do not
|
2012-07-02 20:01:25 +02:00
|
|
|
* let maybe_die_on_misspelt_object_name() even trigger.
|
2011-05-10 21:05:01 +02:00
|
|
|
*/
|
|
|
|
if (!(arg[0] == ':' && !isalnum(arg[1])))
|
2012-07-02 20:01:25 +02:00
|
|
|
maybe_die_on_misspelt_object_name(arg, prefix);
|
2011-05-10 21:05:01 +02:00
|
|
|
|
2009-12-07 11:10:50 +01:00
|
|
|
/* ... or fall back the most general message. */
|
|
|
|
die("ambiguous argument '%s': unknown revision or path not in the working tree.\n"
|
2012-08-03 10:21:20 +02:00
|
|
|
"Use '--' to separate paths from revisions, like this:\n"
|
|
|
|
"'git <command> [<revision>...] -- [<file>...]'", arg);
|
2009-12-07 11:10:50 +01:00
|
|
|
|
|
|
|
}
|
|
|
|
|
2006-04-26 19:15:54 +02:00
|
|
|
/*
|
|
|
|
* Verify a filename that we got as an argument for a pathspec
|
|
|
|
* entry. Note that a filename that begins with "-" never verifies
|
|
|
|
* as true, because even if such a filename were to exist, we want
|
|
|
|
* it to be preceded by the "--" marker (or we want the user to
|
|
|
|
* use a format like "./-filename")
|
2012-06-18 20:18:21 +02:00
|
|
|
*
|
|
|
|
* The "diagnose_misspelt_rev" is used to provide a user-friendly
|
|
|
|
* diagnosis when dying upon finding that "name" is not a pathname.
|
|
|
|
* If set to 1, the diagnosis will try to diagnose "name" as an
|
|
|
|
* invalid object name (e.g. HEAD:foo). If set to 0, the diagnosis
|
|
|
|
* will only complain about an inexisting file.
|
|
|
|
*
|
|
|
|
* This function is typically called to check that a "file or rev"
|
|
|
|
* argument is unambiguous. In this case, the caller will want
|
|
|
|
* diagnose_misspelt_rev == 1 when verifying the first non-rev
|
|
|
|
* argument (which could have been a revision), and
|
|
|
|
* diagnose_misspelt_rev == 0 for the next ones (because we already
|
|
|
|
* saw a filename, there's not ambiguity anymore).
|
2006-04-26 19:15:54 +02:00
|
|
|
*/
|
2012-06-18 20:18:21 +02:00
|
|
|
void verify_filename(const char *prefix,
|
|
|
|
const char *arg,
|
|
|
|
int diagnose_misspelt_rev)
|
2006-04-26 19:15:54 +02:00
|
|
|
{
|
|
|
|
if (*arg == '-')
|
|
|
|
die("bad flag '%s' used after filename", arg);
|
2009-10-18 09:27:24 +02:00
|
|
|
if (check_filename(prefix, arg))
|
2006-04-26 19:15:54 +02:00
|
|
|
return;
|
2012-06-18 20:18:21 +02:00
|
|
|
die_verify_filename(prefix, arg, diagnose_misspelt_rev);
|
2006-04-26 19:15:54 +02:00
|
|
|
}
|
|
|
|
|
2006-04-27 00:09:27 +02:00
|
|
|
/*
|
|
|
|
* Opposite of the above: the command line did not have -- marker
|
|
|
|
* and we parsed the arg as a refname. It should not be interpretable
|
|
|
|
* as a filename.
|
|
|
|
*/
|
|
|
|
void verify_non_filename(const char *prefix, const char *arg)
|
|
|
|
{
|
2007-06-03 16:48:16 +02:00
|
|
|
if (!is_inside_work_tree() || is_inside_git_dir())
|
2007-01-20 03:09:34 +01:00
|
|
|
return;
|
2006-04-27 00:09:27 +02:00
|
|
|
if (*arg == '-')
|
|
|
|
return; /* flag */
|
2009-10-18 09:27:24 +02:00
|
|
|
if (!check_filename(prefix, arg))
|
|
|
|
return;
|
|
|
|
die("ambiguous argument '%s': both revision and filename\n"
|
2012-08-03 10:21:20 +02:00
|
|
|
"Use '--' to separate paths from revisions, like this:\n"
|
|
|
|
"'git <command> [<revision>...] -- [<file>...]'", arg);
|
2006-04-27 00:09:27 +02:00
|
|
|
}
|
|
|
|
|
2011-04-07 01:11:56 +02:00
|
|
|
/*
|
|
|
|
* Magic pathspec
|
|
|
|
*
|
|
|
|
* NEEDSWORK: These need to be moved to dir.h or even to a new
|
|
|
|
* pathspec.h when we restructure get_pathspec() users to use the
|
|
|
|
* "struct pathspec" interface.
|
|
|
|
*
|
|
|
|
* Possible future magic semantics include stuff like:
|
|
|
|
*
|
|
|
|
* { PATHSPEC_NOGLOB, '!', "noglob" },
|
2011-05-10 19:23:41 +02:00
|
|
|
* { PATHSPEC_ICASE, '\0', "icase" },
|
2011-04-07 01:11:56 +02:00
|
|
|
* { PATHSPEC_RECURSIVE, '*', "recursive" },
|
|
|
|
* { PATHSPEC_REGEXP, '\0', "regexp" },
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
#define PATHSPEC_FROMTOP (1<<0)
|
|
|
|
|
2011-05-17 19:43:10 +02:00
|
|
|
static struct pathspec_magic {
|
2011-04-07 01:11:56 +02:00
|
|
|
unsigned bit;
|
|
|
|
char mnemonic; /* this cannot be ':'! */
|
|
|
|
const char *name;
|
|
|
|
} pathspec_magic[] = {
|
|
|
|
{ PATHSPEC_FROMTOP, '/', "top" },
|
|
|
|
};
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Take an element of a pathspec and check for magic signatures.
|
|
|
|
* Append the result to the prefix.
|
|
|
|
*
|
|
|
|
* For now, we only parse the syntax and throw out anything other than
|
|
|
|
* "top" magic.
|
|
|
|
*
|
|
|
|
* NEEDSWORK: This needs to be rewritten when we start migrating
|
|
|
|
* get_pathspec() users to use the "struct pathspec" interface. For
|
|
|
|
* example, a pathspec element may be marked as case-insensitive, but
|
|
|
|
* the prefix part must always match literally, and a single stupid
|
|
|
|
* string cannot express such a case.
|
|
|
|
*/
|
2011-05-17 19:43:10 +02:00
|
|
|
static const char *prefix_pathspec(const char *prefix, int prefixlen, const char *elt)
|
2011-04-07 01:11:56 +02:00
|
|
|
{
|
|
|
|
unsigned magic = 0;
|
|
|
|
const char *copyfrom = elt;
|
2011-05-10 19:23:41 +02:00
|
|
|
int i;
|
2011-04-07 01:11:56 +02:00
|
|
|
|
|
|
|
if (elt[0] != ':') {
|
|
|
|
; /* nothing to do */
|
|
|
|
} else if (elt[1] == '(') {
|
|
|
|
/* longhand */
|
|
|
|
const char *nextat;
|
|
|
|
for (copyfrom = elt + 2;
|
|
|
|
*copyfrom && *copyfrom != ')';
|
|
|
|
copyfrom = nextat) {
|
|
|
|
size_t len = strcspn(copyfrom, ",)");
|
2013-03-07 17:36:03 +01:00
|
|
|
if (copyfrom[len] == ',')
|
2011-04-07 01:11:56 +02:00
|
|
|
nextat = copyfrom + len + 1;
|
2013-03-07 17:36:03 +01:00
|
|
|
else
|
|
|
|
/* handle ')' and '\0' */
|
|
|
|
nextat = copyfrom + len;
|
2011-04-07 01:11:56 +02:00
|
|
|
if (!len)
|
|
|
|
continue;
|
|
|
|
for (i = 0; i < ARRAY_SIZE(pathspec_magic); i++)
|
|
|
|
if (strlen(pathspec_magic[i].name) == len &&
|
|
|
|
!strncmp(pathspec_magic[i].name, copyfrom, len)) {
|
|
|
|
magic |= pathspec_magic[i].bit;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
if (ARRAY_SIZE(pathspec_magic) <= i)
|
|
|
|
die("Invalid pathspec magic '%.*s' in '%s'",
|
|
|
|
(int) len, copyfrom, elt);
|
|
|
|
}
|
2013-03-10 00:46:00 +01:00
|
|
|
if (*copyfrom != ')')
|
|
|
|
die("Missing ')' at the end of pathspec magic in '%s'", elt);
|
|
|
|
copyfrom++;
|
2011-04-07 01:11:56 +02:00
|
|
|
} else {
|
|
|
|
/* shorthand */
|
|
|
|
for (copyfrom = elt + 1;
|
|
|
|
*copyfrom && *copyfrom != ':';
|
|
|
|
copyfrom++) {
|
|
|
|
char ch = *copyfrom;
|
2011-04-09 01:18:46 +02:00
|
|
|
|
|
|
|
if (!is_pathspec_magic(ch))
|
|
|
|
break;
|
2011-04-07 01:11:56 +02:00
|
|
|
for (i = 0; i < ARRAY_SIZE(pathspec_magic); i++)
|
|
|
|
if (pathspec_magic[i].mnemonic == ch) {
|
|
|
|
magic |= pathspec_magic[i].bit;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
if (ARRAY_SIZE(pathspec_magic) <= i)
|
2011-04-09 01:18:46 +02:00
|
|
|
die("Unimplemented pathspec magic '%c' in '%s'",
|
|
|
|
ch, elt);
|
2011-04-07 01:11:56 +02:00
|
|
|
}
|
|
|
|
if (*copyfrom == ':')
|
|
|
|
copyfrom++;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (magic & PATHSPEC_FROMTOP)
|
2011-05-10 19:23:41 +02:00
|
|
|
return xstrdup(copyfrom);
|
2011-04-07 01:11:56 +02:00
|
|
|
else
|
2011-05-10 19:23:41 +02:00
|
|
|
return prefix_path(prefix, prefixlen, copyfrom);
|
2011-04-07 01:11:56 +02:00
|
|
|
}
|
|
|
|
|
2013-01-06 17:58:12 +01:00
|
|
|
/*
|
|
|
|
* N.B. get_pathspec() is deprecated in favor of the "struct pathspec"
|
|
|
|
* based interface - see pathspec_magic above.
|
|
|
|
*
|
|
|
|
* Arguments:
|
|
|
|
* - prefix - a path relative to the root of the working tree
|
|
|
|
* - pathspec - a list of paths underneath the prefix path
|
|
|
|
*
|
|
|
|
* Iterates over pathspec, prepending each path with prefix,
|
|
|
|
* and return the resulting list.
|
|
|
|
*
|
|
|
|
* If pathspec is empty, return a singleton list containing prefix.
|
|
|
|
*
|
|
|
|
* If pathspec and prefix are both empty, return an empty list.
|
|
|
|
*
|
|
|
|
* This is typically used by built-in commands such as add.c, in order
|
|
|
|
* to normalize argv arguments provided to the built-in into a list of
|
|
|
|
* paths to process, all relative to the root of the working tree.
|
|
|
|
*/
|
2005-09-21 09:00:47 +02:00
|
|
|
const char **get_pathspec(const char *prefix, const char **pathspec)
|
2005-08-17 03:06:34 +02:00
|
|
|
{
|
2005-09-21 09:00:47 +02:00
|
|
|
const char *entry = *pathspec;
|
setup: sanitize absolute and funny paths in get_pathspec()
The prefix_path() function called from get_pathspec() is
responsible for translating list of user-supplied pathspecs to
list of pathspecs that is relative to the root of the work
tree. When working inside a subdirectory, the user-supplied
pathspecs are taken to be relative to the current subdirectory.
Among special path components in pathspecs, we used to accept
and interpret only "." ("the directory", meaning a no-op) and
".." ("up one level") at the beginning. Everything else was
passed through as-is.
For example, if you are in Documentation/ directory of the
project, you can name Documentation/howto/maintain-git.txt as:
howto/maintain-git.txt
../Documentation/howto/maitain-git.txt
../././Documentation/howto/maitain-git.txt
but not as:
howto/./maintain-git.txt
$(pwd)/howto/maintain-git.txt
This patch updates prefix_path() in several ways:
- If the pathspec is not absolute, prefix (i.e. the current
subdirectory relative to the root of the work tree, with
terminating slash, if not empty) and the pathspec is
concatenated first and used in the next step. Otherwise,
that absolute pathspec is used in the next step.
- Then special path components "." (no-op) and ".." (up one
level) are interpreted to simplify the path. It is an error
to have too many ".." to cause the intermediate result to
step outside of the input to this step.
- If the original pathspec was not absolute, the result from
the previous step is the resulting "sanitized" pathspec.
Otherwise, the result from the previous step is still
absolute, and it is an error if it does not begin with the
directory that corresponds to the root of the work tree. The
directory is stripped away from the result and is returned.
- In any case, the resulting pathspec in the array
get_pathspec() returns omit the ones that caused errors.
With this patch, the last two examples also behave as expected.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-01-29 07:44:27 +01:00
|
|
|
const char **src, **dst;
|
2005-08-17 03:06:34 +02:00
|
|
|
int prefixlen;
|
|
|
|
|
2005-08-17 05:44:32 +02:00
|
|
|
if (!prefix && !entry)
|
|
|
|
return NULL;
|
2005-08-17 03:06:34 +02:00
|
|
|
|
|
|
|
if (!entry) {
|
|
|
|
static const char *spec[2];
|
|
|
|
spec[0] = prefix;
|
|
|
|
spec[1] = NULL;
|
|
|
|
return spec;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Otherwise we have to re-write the entries.. */
|
setup: sanitize absolute and funny paths in get_pathspec()
The prefix_path() function called from get_pathspec() is
responsible for translating list of user-supplied pathspecs to
list of pathspecs that is relative to the root of the work
tree. When working inside a subdirectory, the user-supplied
pathspecs are taken to be relative to the current subdirectory.
Among special path components in pathspecs, we used to accept
and interpret only "." ("the directory", meaning a no-op) and
".." ("up one level") at the beginning. Everything else was
passed through as-is.
For example, if you are in Documentation/ directory of the
project, you can name Documentation/howto/maintain-git.txt as:
howto/maintain-git.txt
../Documentation/howto/maitain-git.txt
../././Documentation/howto/maitain-git.txt
but not as:
howto/./maintain-git.txt
$(pwd)/howto/maintain-git.txt
This patch updates prefix_path() in several ways:
- If the pathspec is not absolute, prefix (i.e. the current
subdirectory relative to the root of the work tree, with
terminating slash, if not empty) and the pathspec is
concatenated first and used in the next step. Otherwise,
that absolute pathspec is used in the next step.
- Then special path components "." (no-op) and ".." (up one
level) are interpreted to simplify the path. It is an error
to have too many ".." to cause the intermediate result to
step outside of the input to this step.
- If the original pathspec was not absolute, the result from
the previous step is the resulting "sanitized" pathspec.
Otherwise, the result from the previous step is still
absolute, and it is an error if it does not begin with the
directory that corresponds to the root of the work tree. The
directory is stripped away from the result and is returned.
- In any case, the resulting pathspec in the array
get_pathspec() returns omit the ones that caused errors.
With this patch, the last two examples also behave as expected.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-01-29 07:44:27 +01:00
|
|
|
src = pathspec;
|
|
|
|
dst = pathspec;
|
2005-08-17 05:44:32 +02:00
|
|
|
prefixlen = prefix ? strlen(prefix) : 0;
|
setup: sanitize absolute and funny paths in get_pathspec()
The prefix_path() function called from get_pathspec() is
responsible for translating list of user-supplied pathspecs to
list of pathspecs that is relative to the root of the work
tree. When working inside a subdirectory, the user-supplied
pathspecs are taken to be relative to the current subdirectory.
Among special path components in pathspecs, we used to accept
and interpret only "." ("the directory", meaning a no-op) and
".." ("up one level") at the beginning. Everything else was
passed through as-is.
For example, if you are in Documentation/ directory of the
project, you can name Documentation/howto/maintain-git.txt as:
howto/maintain-git.txt
../Documentation/howto/maitain-git.txt
../././Documentation/howto/maitain-git.txt
but not as:
howto/./maintain-git.txt
$(pwd)/howto/maintain-git.txt
This patch updates prefix_path() in several ways:
- If the pathspec is not absolute, prefix (i.e. the current
subdirectory relative to the root of the work tree, with
terminating slash, if not empty) and the pathspec is
concatenated first and used in the next step. Otherwise,
that absolute pathspec is used in the next step.
- Then special path components "." (no-op) and ".." (up one
level) are interpreted to simplify the path. It is an error
to have too many ".." to cause the intermediate result to
step outside of the input to this step.
- If the original pathspec was not absolute, the result from
the previous step is the resulting "sanitized" pathspec.
Otherwise, the result from the previous step is still
absolute, and it is an error if it does not begin with the
directory that corresponds to the root of the work tree. The
directory is stripped away from the result and is returned.
- In any case, the resulting pathspec in the array
get_pathspec() returns omit the ones that caused errors.
With this patch, the last two examples also behave as expected.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-01-29 07:44:27 +01:00
|
|
|
while (*src) {
|
2011-04-07 01:11:56 +02:00
|
|
|
*(dst++) = prefix_pathspec(prefix, prefixlen, *src);
|
setup: sanitize absolute and funny paths in get_pathspec()
The prefix_path() function called from get_pathspec() is
responsible for translating list of user-supplied pathspecs to
list of pathspecs that is relative to the root of the work
tree. When working inside a subdirectory, the user-supplied
pathspecs are taken to be relative to the current subdirectory.
Among special path components in pathspecs, we used to accept
and interpret only "." ("the directory", meaning a no-op) and
".." ("up one level") at the beginning. Everything else was
passed through as-is.
For example, if you are in Documentation/ directory of the
project, you can name Documentation/howto/maintain-git.txt as:
howto/maintain-git.txt
../Documentation/howto/maitain-git.txt
../././Documentation/howto/maitain-git.txt
but not as:
howto/./maintain-git.txt
$(pwd)/howto/maintain-git.txt
This patch updates prefix_path() in several ways:
- If the pathspec is not absolute, prefix (i.e. the current
subdirectory relative to the root of the work tree, with
terminating slash, if not empty) and the pathspec is
concatenated first and used in the next step. Otherwise,
that absolute pathspec is used in the next step.
- Then special path components "." (no-op) and ".." (up one
level) are interpreted to simplify the path. It is an error
to have too many ".." to cause the intermediate result to
step outside of the input to this step.
- If the original pathspec was not absolute, the result from
the previous step is the resulting "sanitized" pathspec.
Otherwise, the result from the previous step is still
absolute, and it is an error if it does not begin with the
directory that corresponds to the root of the work tree. The
directory is stripped away from the result and is returned.
- In any case, the resulting pathspec in the array
get_pathspec() returns omit the ones that caused errors.
With this patch, the last two examples also behave as expected.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-01-29 07:44:27 +01:00
|
|
|
src++;
|
|
|
|
}
|
|
|
|
*dst = NULL;
|
|
|
|
if (!*pathspec)
|
|
|
|
return NULL;
|
|
|
|
return pathspec;
|
2005-08-17 03:06:34 +02:00
|
|
|
}
|
|
|
|
|
[PATCH] Make .git directory validation code test HEAD
Inspired by a report by Kalle Valo, this changes git-sh-setup-script and
the "setup_git_directory()" function to test that $GIT_DIR/HEAD is a
symlink, since a number of core git features depend on that these days.
We used to allow a regular file there, but git-fsck-cache has been
complaining about that for a while, and anything that uses branches
depends on the HEAD file being a symlink, so let's just encode that as a
fundamental requirement.
Before, a non-symlink HEAD file would appear to work, but have subtle bugs
like not having the HEAD show up as a valid reference (because it wasn't
under "refs"). Now, we will complain loudly, and the user can fix it up
trivially instead of getting strange behaviour.
This also removes the tests for "$GIT_DIR" and "$GIT_OBJECT_DIRECTORY"
being directories, since the other tests will implicitly test for that
anyway (ie the tests for HEAD, refs and 00 would fail).
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-27 22:54:42 +02:00
|
|
|
/*
|
2006-12-31 05:30:19 +01:00
|
|
|
* Test if it looks like we're at a git directory.
|
2005-11-26 00:43:41 +01:00
|
|
|
* We want to see:
|
[PATCH] Make .git directory validation code test HEAD
Inspired by a report by Kalle Valo, this changes git-sh-setup-script and
the "setup_git_directory()" function to test that $GIT_DIR/HEAD is a
symlink, since a number of core git features depend on that these days.
We used to allow a regular file there, but git-fsck-cache has been
complaining about that for a while, and anything that uses branches
depends on the HEAD file being a symlink, so let's just encode that as a
fundamental requirement.
Before, a non-symlink HEAD file would appear to work, but have subtle bugs
like not having the HEAD show up as a valid reference (because it wasn't
under "refs"). Now, we will complain loudly, and the user can fix it up
trivially instead of getting strange behaviour.
This also removes the tests for "$GIT_DIR" and "$GIT_OBJECT_DIRECTORY"
being directories, since the other tests will implicitly test for that
anyway (ie the tests for HEAD, refs and 00 would fail).
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-27 22:54:42 +02:00
|
|
|
*
|
2008-01-03 15:18:07 +01:00
|
|
|
* - either an objects/ directory _or_ the proper
|
[PATCH] Make .git directory validation code test HEAD
Inspired by a report by Kalle Valo, this changes git-sh-setup-script and
the "setup_git_directory()" function to test that $GIT_DIR/HEAD is a
symlink, since a number of core git features depend on that these days.
We used to allow a regular file there, but git-fsck-cache has been
complaining about that for a while, and anything that uses branches
depends on the HEAD file being a symlink, so let's just encode that as a
fundamental requirement.
Before, a non-symlink HEAD file would appear to work, but have subtle bugs
like not having the HEAD show up as a valid reference (because it wasn't
under "refs"). Now, we will complain loudly, and the user can fix it up
trivially instead of getting strange behaviour.
This also removes the tests for "$GIT_DIR" and "$GIT_OBJECT_DIRECTORY"
being directories, since the other tests will implicitly test for that
anyway (ie the tests for HEAD, refs and 00 would fail).
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-27 22:54:42 +02:00
|
|
|
* GIT_OBJECT_DIRECTORY environment variable
|
2006-12-31 05:30:19 +01:00
|
|
|
* - a refs/ directory
|
2005-09-30 23:26:57 +02:00
|
|
|
* - either a HEAD symlink or a HEAD file that is formatted as
|
2007-01-02 08:31:08 +01:00
|
|
|
* a proper "ref:", or a regular file HEAD that has a properly
|
|
|
|
* formatted sha1 object name.
|
[PATCH] Make .git directory validation code test HEAD
Inspired by a report by Kalle Valo, this changes git-sh-setup-script and
the "setup_git_directory()" function to test that $GIT_DIR/HEAD is a
symlink, since a number of core git features depend on that these days.
We used to allow a regular file there, but git-fsck-cache has been
complaining about that for a while, and anything that uses branches
depends on the HEAD file being a symlink, so let's just encode that as a
fundamental requirement.
Before, a non-symlink HEAD file would appear to work, but have subtle bugs
like not having the HEAD show up as a valid reference (because it wasn't
under "refs"). Now, we will complain loudly, and the user can fix it up
trivially instead of getting strange behaviour.
This also removes the tests for "$GIT_DIR" and "$GIT_OBJECT_DIRECTORY"
being directories, since the other tests will implicitly test for that
anyway (ie the tests for HEAD, refs and 00 would fail).
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-27 22:54:42 +02:00
|
|
|
*/
|
standardize and improve lookup rules for external local repos
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 <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-02 22:59:13 +01:00
|
|
|
int is_git_directory(const char *suspect)
|
[PATCH] Make .git directory validation code test HEAD
Inspired by a report by Kalle Valo, this changes git-sh-setup-script and
the "setup_git_directory()" function to test that $GIT_DIR/HEAD is a
symlink, since a number of core git features depend on that these days.
We used to allow a regular file there, but git-fsck-cache has been
complaining about that for a while, and anything that uses branches
depends on the HEAD file being a symlink, so let's just encode that as a
fundamental requirement.
Before, a non-symlink HEAD file would appear to work, but have subtle bugs
like not having the HEAD show up as a valid reference (because it wasn't
under "refs"). Now, we will complain loudly, and the user can fix it up
trivially instead of getting strange behaviour.
This also removes the tests for "$GIT_DIR" and "$GIT_OBJECT_DIRECTORY"
being directories, since the other tests will implicitly test for that
anyway (ie the tests for HEAD, refs and 00 would fail).
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-27 22:54:42 +02:00
|
|
|
{
|
2006-12-31 05:30:19 +01:00
|
|
|
char path[PATH_MAX];
|
|
|
|
size_t len = strlen(suspect);
|
|
|
|
|
2010-07-20 06:46:21 +02:00
|
|
|
if (PATH_MAX <= len + strlen("/objects"))
|
|
|
|
die("Too long path: %.*s", 60, suspect);
|
2006-12-31 05:30:19 +01:00
|
|
|
strcpy(path, suspect);
|
|
|
|
if (getenv(DB_ENVIRONMENT)) {
|
|
|
|
if (access(getenv(DB_ENVIRONMENT), X_OK))
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
strcpy(path + len, "/objects");
|
|
|
|
if (access(path, X_OK))
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
strcpy(path + len, "/refs");
|
|
|
|
if (access(path, X_OK))
|
2005-09-30 23:26:57 +02:00
|
|
|
return 0;
|
2006-12-31 05:30:19 +01:00
|
|
|
|
|
|
|
strcpy(path + len, "/HEAD");
|
2007-01-02 08:31:08 +01:00
|
|
|
if (validate_headref(path))
|
2006-12-31 05:30:19 +01:00
|
|
|
return 0;
|
|
|
|
|
2005-09-30 23:26:57 +02:00
|
|
|
return 1;
|
[PATCH] Make .git directory validation code test HEAD
Inspired by a report by Kalle Valo, this changes git-sh-setup-script and
the "setup_git_directory()" function to test that $GIT_DIR/HEAD is a
symlink, since a number of core git features depend on that these days.
We used to allow a regular file there, but git-fsck-cache has been
complaining about that for a while, and anything that uses branches
depends on the HEAD file being a symlink, so let's just encode that as a
fundamental requirement.
Before, a non-symlink HEAD file would appear to work, but have subtle bugs
like not having the HEAD show up as a valid reference (because it wasn't
under "refs"). Now, we will complain loudly, and the user can fix it up
trivially instead of getting strange behaviour.
This also removes the tests for "$GIT_DIR" and "$GIT_OBJECT_DIRECTORY"
being directories, since the other tests will implicitly test for that
anyway (ie the tests for HEAD, refs and 00 would fail).
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-27 22:54:42 +02:00
|
|
|
}
|
|
|
|
|
2007-01-20 03:09:34 +01:00
|
|
|
int is_inside_git_dir(void)
|
|
|
|
{
|
Clean up work-tree handling
The old version of work-tree support was an unholy mess, barely readable,
and not to the point.
For example, why do you have to provide a worktree, when it is not used?
As in "git status". Now it works.
Another riddle was: if you can have work trees inside the git dir, why
are some programs complaining that they need a work tree?
IOW it is allowed to call
$ git --git-dir=../ --work-tree=. bla
when you really want to. In this case, you are both in the git directory
and in the working tree. So, programs have to actually test for the right
thing, namely if they are inside a working tree, and not if they are
inside a git directory.
Also, GIT_DIR=../.git should behave the same as if no GIT_DIR was
specified, unless there is a repository in the current working directory.
It does now.
The logic to determine if a repository is bare, or has a work tree
(tertium non datur), is this:
--work-tree=bla overrides GIT_WORK_TREE, which overrides core.bare = true,
which overrides core.worktree, which overrides GIT_DIR/.. when GIT_DIR
ends in /.git, which overrides the directory in which .git/ was found.
In related news, a long standing bug was fixed: when in .git/bla/x.git/,
which is a bare repository, git formerly assumed ../.. to be the
appropriate git dir. This problem was reported by Shawn Pearce to have
caused much pain, where a colleague mistakenly ran "git init" in "/" a
long time ago, and bare repositories just would not work.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-08-01 02:30:14 +02:00
|
|
|
if (inside_git_dir < 0)
|
|
|
|
inside_git_dir = is_inside_dir(get_git_dir());
|
|
|
|
return inside_git_dir;
|
2007-06-06 09:10:42 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
int is_inside_work_tree(void)
|
|
|
|
{
|
Clean up work-tree handling
The old version of work-tree support was an unholy mess, barely readable,
and not to the point.
For example, why do you have to provide a worktree, when it is not used?
As in "git status". Now it works.
Another riddle was: if you can have work trees inside the git dir, why
are some programs complaining that they need a work tree?
IOW it is allowed to call
$ git --git-dir=../ --work-tree=. bla
when you really want to. In this case, you are both in the git directory
and in the working tree. So, programs have to actually test for the right
thing, namely if they are inside a working tree, and not if they are
inside a git directory.
Also, GIT_DIR=../.git should behave the same as if no GIT_DIR was
specified, unless there is a repository in the current working directory.
It does now.
The logic to determine if a repository is bare, or has a work tree
(tertium non datur), is this:
--work-tree=bla overrides GIT_WORK_TREE, which overrides core.bare = true,
which overrides core.worktree, which overrides GIT_DIR/.. when GIT_DIR
ends in /.git, which overrides the directory in which .git/ was found.
In related news, a long standing bug was fixed: when in .git/bla/x.git/,
which is a bare repository, git formerly assumed ../.. to be the
appropriate git dir. This problem was reported by Shawn Pearce to have
caused much pain, where a colleague mistakenly ran "git init" in "/" a
long time ago, and bare repositories just would not work.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-08-01 02:30:14 +02:00
|
|
|
if (inside_work_tree < 0)
|
|
|
|
inside_work_tree = is_inside_dir(get_git_work_tree());
|
|
|
|
return inside_work_tree;
|
2007-06-06 09:10:42 +02:00
|
|
|
}
|
|
|
|
|
2007-11-09 00:35:32 +01:00
|
|
|
void setup_work_tree(void)
|
|
|
|
{
|
2007-11-09 12:34:07 +01:00
|
|
|
const char *work_tree, *git_dir;
|
|
|
|
static int initialized = 0;
|
|
|
|
|
|
|
|
if (initialized)
|
|
|
|
return;
|
|
|
|
work_tree = get_git_work_tree();
|
|
|
|
git_dir = get_git_dir();
|
2007-11-03 12:23:11 +01:00
|
|
|
if (!is_absolute_path(git_dir))
|
2011-03-17 12:26:46 +01:00
|
|
|
git_dir = real_path(get_git_dir());
|
2007-11-03 12:23:11 +01:00
|
|
|
if (!work_tree || chdir(work_tree))
|
|
|
|
die("This operation must be run in a work tree");
|
2010-12-27 02:26:04 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Make sure subsequent git processes find correct worktree
|
|
|
|
* if $GIT_WORK_TREE is set relative
|
|
|
|
*/
|
|
|
|
if (getenv(GIT_WORK_TREE_ENVIRONMENT))
|
|
|
|
setenv(GIT_WORK_TREE_ENVIRONMENT, ".", 1);
|
|
|
|
|
2011-03-17 12:26:46 +01:00
|
|
|
set_git_dir(relative_path(git_dir, work_tree));
|
2007-11-09 12:34:07 +01:00
|
|
|
initialized = 1;
|
2007-11-03 12:23:11 +01:00
|
|
|
}
|
|
|
|
|
2010-11-26 16:32:34 +01:00
|
|
|
static int check_repository_format_gently(const char *gitdir, int *nongit_ok)
|
2007-12-05 14:33:32 +01:00
|
|
|
{
|
2010-11-26 16:32:34 +01:00
|
|
|
char repo_config[PATH_MAX+1];
|
|
|
|
|
|
|
|
/*
|
|
|
|
* git_config() can't be used here because it calls git_pathdup()
|
|
|
|
* to get $GIT_CONFIG/config. That call will make setup_git_env()
|
|
|
|
* set git_dir to ".git".
|
|
|
|
*
|
|
|
|
* We are in gitdir setup, no git dir has been found useable yet.
|
|
|
|
* Use a gentler version of git_config() to check if this repo
|
|
|
|
* is a good one.
|
|
|
|
*/
|
|
|
|
snprintf(repo_config, PATH_MAX, "%s/config", gitdir);
|
|
|
|
git_config_early(check_repository_format_version, NULL, repo_config);
|
2007-12-05 14:33:32 +01:00
|
|
|
if (GIT_REPO_VERSION < repository_format_version) {
|
|
|
|
if (!nongit_ok)
|
|
|
|
die ("Expected git repo version <= %d, found %d",
|
|
|
|
GIT_REPO_VERSION, repository_format_version);
|
|
|
|
warning("Expected git repo version <= %d, found %d",
|
|
|
|
GIT_REPO_VERSION, repository_format_version);
|
|
|
|
warning("Please upgrade Git");
|
|
|
|
*nongit_ok = -1;
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2008-02-20 23:13:13 +01:00
|
|
|
/*
|
|
|
|
* Try to read the location of the git directory from the .git file,
|
|
|
|
* return path to git directory if found.
|
|
|
|
*/
|
2011-08-22 23:04:56 +02:00
|
|
|
const char *read_gitfile(const char *path)
|
2008-02-20 23:13:13 +01:00
|
|
|
{
|
|
|
|
char *buf;
|
2010-01-09 04:36:41 +01:00
|
|
|
char *dir;
|
|
|
|
const char *slash;
|
2008-02-20 23:13:13 +01:00
|
|
|
struct stat st;
|
|
|
|
int fd;
|
2011-05-26 18:28:44 +02:00
|
|
|
ssize_t len;
|
2008-02-20 23:13:13 +01:00
|
|
|
|
|
|
|
if (stat(path, &st))
|
|
|
|
return NULL;
|
|
|
|
if (!S_ISREG(st.st_mode))
|
|
|
|
return NULL;
|
|
|
|
fd = open(path, O_RDONLY);
|
|
|
|
if (fd < 0)
|
2009-06-27 17:58:46 +02:00
|
|
|
die_errno("Error opening '%s'", path);
|
2008-02-20 23:13:13 +01:00
|
|
|
buf = xmalloc(st.st_size + 1);
|
|
|
|
len = read_in_full(fd, buf, st.st_size);
|
|
|
|
close(fd);
|
|
|
|
if (len != st.st_size)
|
|
|
|
die("Error reading %s", path);
|
|
|
|
buf[len] = '\0';
|
|
|
|
if (prefixcmp(buf, "gitdir: "))
|
|
|
|
die("Invalid gitfile format: %s", path);
|
|
|
|
while (buf[len - 1] == '\n' || buf[len - 1] == '\r')
|
|
|
|
len--;
|
|
|
|
if (len < 9)
|
|
|
|
die("No path in gitfile: %s", path);
|
|
|
|
buf[len] = '\0';
|
2010-01-09 04:36:41 +01:00
|
|
|
dir = buf + 8;
|
|
|
|
|
|
|
|
if (!is_absolute_path(dir) && (slash = strrchr(path, '/'))) {
|
|
|
|
size_t pathlen = slash+1 - path;
|
|
|
|
size_t dirlen = pathlen + len - 8;
|
|
|
|
dir = xmalloc(dirlen + 1);
|
|
|
|
strncpy(dir, path, pathlen);
|
|
|
|
strncpy(dir + pathlen, buf + 8, len - 8);
|
|
|
|
dir[dirlen] = '\0';
|
|
|
|
free(buf);
|
|
|
|
buf = dir;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!is_git_directory(dir))
|
|
|
|
die("Not a git repository: %s", dir);
|
2011-03-17 12:26:46 +01:00
|
|
|
path = real_path(dir);
|
2010-01-09 04:36:41 +01:00
|
|
|
|
2008-02-20 23:13:13 +01:00
|
|
|
free(buf);
|
|
|
|
return path;
|
|
|
|
}
|
|
|
|
|
2010-07-24 13:19:44 +02:00
|
|
|
static const char *setup_explicit_git_dir(const char *gitdirenv,
|
2010-11-26 16:32:39 +01:00
|
|
|
char *cwd, int len,
|
|
|
|
int *nongit_ok)
|
2010-07-24 13:19:44 +02:00
|
|
|
{
|
2010-11-26 16:32:39 +01:00
|
|
|
const char *work_tree_env = getenv(GIT_WORK_TREE_ENVIRONMENT);
|
|
|
|
const char *worktree;
|
|
|
|
char *gitfile;
|
2011-03-26 10:04:24 +01:00
|
|
|
int offset;
|
2010-07-24 13:19:44 +02:00
|
|
|
|
|
|
|
if (PATH_MAX - 40 < strlen(gitdirenv))
|
|
|
|
die("'$%s' too big", GIT_DIR_ENVIRONMENT);
|
2010-11-26 16:32:39 +01:00
|
|
|
|
2011-08-22 23:04:56 +02:00
|
|
|
gitfile = (char*)read_gitfile(gitdirenv);
|
2010-11-26 16:32:39 +01:00
|
|
|
if (gitfile) {
|
|
|
|
gitfile = xstrdup(gitfile);
|
|
|
|
gitdirenv = gitfile;
|
|
|
|
}
|
|
|
|
|
2010-07-24 13:19:44 +02:00
|
|
|
if (!is_git_directory(gitdirenv)) {
|
|
|
|
if (nongit_ok) {
|
|
|
|
*nongit_ok = 1;
|
2010-11-26 16:32:39 +01:00
|
|
|
free(gitfile);
|
2010-07-24 13:19:44 +02:00
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
die("Not a git repository: '%s'", gitdirenv);
|
|
|
|
}
|
2010-11-26 16:32:39 +01:00
|
|
|
|
|
|
|
if (check_repository_format_gently(gitdirenv, nongit_ok)) {
|
|
|
|
free(gitfile);
|
|
|
|
return NULL;
|
2010-07-24 13:19:44 +02:00
|
|
|
}
|
2010-11-26 16:32:39 +01:00
|
|
|
|
|
|
|
/* #3, #7, #11, #15, #19, #23, #27, #31 (see t1510) */
|
|
|
|
if (work_tree_env)
|
|
|
|
set_git_work_tree(work_tree_env);
|
|
|
|
else if (is_bare_repository_cfg > 0) {
|
|
|
|
if (git_work_tree_cfg) /* #22.2, #30 */
|
|
|
|
die("core.bare and core.worktree do not make sense");
|
|
|
|
|
|
|
|
/* #18, #26 */
|
|
|
|
set_git_dir(gitdirenv);
|
|
|
|
free(gitfile);
|
2010-07-24 13:19:44 +02:00
|
|
|
return NULL;
|
2010-11-26 16:32:39 +01:00
|
|
|
}
|
|
|
|
else if (git_work_tree_cfg) { /* #6, #14 */
|
|
|
|
if (is_absolute_path(git_work_tree_cfg))
|
|
|
|
set_git_work_tree(git_work_tree_cfg);
|
|
|
|
else {
|
|
|
|
char core_worktree[PATH_MAX];
|
|
|
|
if (chdir(gitdirenv))
|
|
|
|
die_errno("Could not chdir to '%s'", gitdirenv);
|
|
|
|
if (chdir(git_work_tree_cfg))
|
|
|
|
die_errno("Could not chdir to '%s'", git_work_tree_cfg);
|
|
|
|
if (!getcwd(core_worktree, PATH_MAX))
|
|
|
|
die_errno("Could not get directory '%s'", git_work_tree_cfg);
|
|
|
|
if (chdir(cwd))
|
|
|
|
die_errno("Could not come back to cwd");
|
|
|
|
set_git_work_tree(core_worktree);
|
|
|
|
}
|
|
|
|
}
|
setup: suppress implicit "." work-tree for bare repos
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 <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-08 10:32:22 +01:00
|
|
|
else if (!git_env_bool(GIT_IMPLICIT_WORK_TREE_ENVIRONMENT, 1)) {
|
|
|
|
/* #16d */
|
|
|
|
set_git_dir(gitdirenv);
|
|
|
|
free(gitfile);
|
|
|
|
return NULL;
|
|
|
|
}
|
2010-11-26 16:32:39 +01:00
|
|
|
else /* #2, #10 */
|
|
|
|
set_git_work_tree(".");
|
|
|
|
|
|
|
|
/* set_git_work_tree() must have been called by now */
|
|
|
|
worktree = get_git_work_tree();
|
|
|
|
|
|
|
|
/* both get_git_work_tree() and cwd are already normalized */
|
|
|
|
if (!strcmp(cwd, worktree)) { /* cwd == worktree */
|
|
|
|
set_git_dir(gitdirenv);
|
|
|
|
free(gitfile);
|
2010-07-24 13:19:44 +02:00
|
|
|
return NULL;
|
2010-11-26 16:32:39 +01:00
|
|
|
}
|
2010-07-24 13:19:44 +02:00
|
|
|
|
2011-03-26 10:04:24 +01:00
|
|
|
offset = dir_inside_of(cwd, worktree);
|
|
|
|
if (offset >= 0) { /* cwd inside worktree? */
|
2011-03-17 12:26:46 +01:00
|
|
|
set_git_dir(real_path(gitdirenv));
|
2010-11-26 16:32:39 +01:00
|
|
|
if (chdir(worktree))
|
|
|
|
die_errno("Could not chdir to '%s'", worktree);
|
|
|
|
cwd[len++] = '/';
|
|
|
|
cwd[len] = '\0';
|
|
|
|
free(gitfile);
|
2011-03-26 10:04:24 +01:00
|
|
|
return cwd + offset;
|
2010-07-24 13:20:15 +02:00
|
|
|
}
|
2010-11-26 16:32:39 +01:00
|
|
|
|
|
|
|
/* cwd outside worktree */
|
|
|
|
set_git_dir(gitdirenv);
|
|
|
|
free(gitfile);
|
|
|
|
return NULL;
|
2010-07-24 13:20:15 +02:00
|
|
|
}
|
|
|
|
|
2010-11-26 16:32:38 +01:00
|
|
|
static const char *setup_discovered_git_dir(const char *gitdir,
|
|
|
|
char *cwd, int offset, int len,
|
|
|
|
int *nongit_ok)
|
2010-07-24 14:11:58 +02:00
|
|
|
{
|
2010-11-26 16:32:38 +01:00
|
|
|
if (check_repository_format_gently(gitdir, nongit_ok))
|
|
|
|
return NULL;
|
2010-07-24 14:11:58 +02:00
|
|
|
|
2011-01-19 13:42:30 +01:00
|
|
|
/* --work-tree is set without --git-dir; use discovered one */
|
|
|
|
if (getenv(GIT_WORK_TREE_ENVIRONMENT) || git_work_tree_cfg) {
|
|
|
|
if (offset != len && !is_absolute_path(gitdir))
|
2011-03-17 12:26:46 +01:00
|
|
|
gitdir = xstrdup(real_path(gitdir));
|
2011-01-19 13:42:30 +01:00
|
|
|
if (chdir(cwd))
|
|
|
|
die_errno("Could not come back to cwd");
|
|
|
|
return setup_explicit_git_dir(gitdir, cwd, len, nongit_ok);
|
|
|
|
}
|
|
|
|
|
2010-11-26 16:32:38 +01:00
|
|
|
/* #16.2, #17.2, #20.2, #21.2, #24, #25, #28, #29 (see t1510) */
|
|
|
|
if (is_bare_repository_cfg > 0) {
|
2011-03-17 12:26:46 +01:00
|
|
|
set_git_dir(offset == len ? gitdir : real_path(gitdir));
|
2010-11-26 16:32:38 +01:00
|
|
|
if (chdir(cwd))
|
|
|
|
die_errno("Could not come back to cwd");
|
2010-07-24 14:11:58 +02:00
|
|
|
return NULL;
|
2010-11-26 16:32:38 +01:00
|
|
|
}
|
2010-07-24 14:11:58 +02:00
|
|
|
|
2010-11-26 16:32:38 +01:00
|
|
|
/* #0, #1, #5, #8, #9, #12, #13 */
|
|
|
|
set_git_work_tree(".");
|
|
|
|
if (strcmp(gitdir, DEFAULT_GIT_DIR_ENVIRONMENT))
|
|
|
|
set_git_dir(gitdir);
|
2010-07-24 14:11:58 +02:00
|
|
|
inside_git_dir = 0;
|
2010-11-26 16:32:38 +01:00
|
|
|
inside_work_tree = 1;
|
2010-07-24 14:11:58 +02:00
|
|
|
if (offset == len)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
/* Make "offset" point to past the '/', and add a '/' at the end */
|
|
|
|
offset++;
|
|
|
|
cwd[len++] = '/';
|
|
|
|
cwd[len] = 0;
|
|
|
|
return cwd + offset;
|
|
|
|
}
|
|
|
|
|
2010-11-26 16:32:36 +01:00
|
|
|
/* #16.1, #17.1, #20.1, #21.1, #22.1 (see t1510) */
|
|
|
|
static const char *setup_bare_git_dir(char *cwd, int offset, int len, int *nongit_ok)
|
2010-07-24 13:25:32 +02:00
|
|
|
{
|
|
|
|
int root_len;
|
|
|
|
|
2010-11-26 16:32:36 +01:00
|
|
|
if (check_repository_format_gently(".", nongit_ok))
|
|
|
|
return NULL;
|
|
|
|
|
setup: suppress implicit "." work-tree for bare repos
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 <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-08 10:32:22 +01:00
|
|
|
setenv(GIT_IMPLICIT_WORK_TREE_ENVIRONMENT, "0", 1);
|
|
|
|
|
2011-01-19 13:42:30 +01:00
|
|
|
/* --work-tree is set without --git-dir; use discovered one */
|
|
|
|
if (getenv(GIT_WORK_TREE_ENVIRONMENT) || git_work_tree_cfg) {
|
|
|
|
const char *gitdir;
|
|
|
|
|
|
|
|
gitdir = offset == len ? "." : xmemdupz(cwd, offset);
|
|
|
|
if (chdir(cwd))
|
|
|
|
die_errno("Could not come back to cwd");
|
|
|
|
return setup_explicit_git_dir(gitdir, cwd, len, nongit_ok);
|
|
|
|
}
|
|
|
|
|
2010-07-24 13:25:32 +02:00
|
|
|
inside_git_dir = 1;
|
2010-11-26 16:32:36 +01:00
|
|
|
inside_work_tree = 0;
|
2010-07-24 13:25:32 +02:00
|
|
|
if (offset != len) {
|
2010-07-24 13:29:41 +02:00
|
|
|
if (chdir(cwd))
|
|
|
|
die_errno("Cannot come back to cwd");
|
2010-07-24 13:25:32 +02:00
|
|
|
root_len = offset_1st_component(cwd);
|
|
|
|
cwd[offset > root_len ? offset : root_len] = '\0';
|
|
|
|
set_git_dir(cwd);
|
2010-11-26 16:32:34 +01:00
|
|
|
}
|
2010-11-26 16:32:36 +01:00
|
|
|
else
|
2010-07-24 13:25:32 +02:00
|
|
|
set_git_dir(".");
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2010-07-24 13:26:41 +02:00
|
|
|
static const char *setup_nongit(const char *cwd, int *nongit_ok)
|
|
|
|
{
|
|
|
|
if (!nongit_ok)
|
|
|
|
die("Not a git repository (or any of the parent directories): %s", DEFAULT_GIT_DIR_ENVIRONMENT);
|
|
|
|
if (chdir(cwd))
|
|
|
|
die_errno("Cannot come back to cwd");
|
|
|
|
*nongit_ok = 1;
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2012-04-13 01:11:36 +02:00
|
|
|
static dev_t get_device_or_die(const char *path, const char *prefix, int prefix_len)
|
2010-07-24 13:27:58 +02:00
|
|
|
{
|
|
|
|
struct stat buf;
|
2012-04-13 01:11:36 +02:00
|
|
|
if (stat(path, &buf)) {
|
|
|
|
die_errno("failed to stat '%*s%s%s'",
|
|
|
|
prefix_len,
|
2010-07-24 13:27:58 +02:00
|
|
|
prefix ? prefix : "",
|
|
|
|
prefix ? "/" : "", path);
|
2012-04-13 01:11:36 +02:00
|
|
|
}
|
2010-07-24 13:27:58 +02:00
|
|
|
return buf.st_dev;
|
|
|
|
}
|
|
|
|
|
2012-10-28 17:16:25 +01:00
|
|
|
/*
|
2012-10-28 17:16:26 +01:00
|
|
|
* A "string_list_each_func_t" function that canonicalizes an entry
|
|
|
|
* from GIT_CEILING_DIRECTORIES using real_path_if_valid(), or
|
Provide a mechanism to turn off symlink resolution in ceiling paths
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 <andersk@mit.edu>
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 <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-20 10:09:24 +01:00
|
|
|
* discards it if unusable. The presence of an empty entry in
|
|
|
|
* GIT_CEILING_DIRECTORIES turns off canonicalization for all
|
|
|
|
* subsequent entries.
|
2012-10-28 17:16:25 +01:00
|
|
|
*/
|
2012-10-28 17:16:26 +01:00
|
|
|
static int canonicalize_ceiling_entry(struct string_list_item *item,
|
Provide a mechanism to turn off symlink resolution in ceiling paths
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 <andersk@mit.edu>
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 <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-20 10:09:24 +01:00
|
|
|
void *cb_data)
|
2012-10-28 17:16:25 +01:00
|
|
|
{
|
Provide a mechanism to turn off symlink resolution in ceiling paths
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 <andersk@mit.edu>
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 <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-20 10:09:24 +01:00
|
|
|
int *empty_entry_found = cb_data;
|
2012-10-28 17:16:26 +01:00
|
|
|
char *ceil = item->string;
|
2012-10-28 17:16:25 +01:00
|
|
|
|
Provide a mechanism to turn off symlink resolution in ceiling paths
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 <andersk@mit.edu>
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 <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-20 10:09:24 +01:00
|
|
|
if (!*ceil) {
|
|
|
|
*empty_entry_found = 1;
|
2012-10-28 17:16:25 +01:00
|
|
|
return 0;
|
Provide a mechanism to turn off symlink resolution in ceiling paths
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 <andersk@mit.edu>
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 <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-20 10:09:24 +01:00
|
|
|
} else if (!is_absolute_path(ceil)) {
|
2012-10-28 17:16:25 +01:00
|
|
|
return 0;
|
Provide a mechanism to turn off symlink resolution in ceiling paths
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 <andersk@mit.edu>
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 <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-20 10:09:24 +01:00
|
|
|
} else if (*empty_entry_found) {
|
|
|
|
/* Keep entry but do not canonicalize it */
|
|
|
|
return 1;
|
|
|
|
} else {
|
|
|
|
const char *real_path = real_path_if_valid(ceil);
|
|
|
|
if (!real_path)
|
|
|
|
return 0;
|
|
|
|
free(item->string);
|
|
|
|
item->string = xstrdup(real_path);
|
|
|
|
return 1;
|
|
|
|
}
|
2012-10-28 17:16:25 +01:00
|
|
|
}
|
|
|
|
|
Clean up work-tree handling
The old version of work-tree support was an unholy mess, barely readable,
and not to the point.
For example, why do you have to provide a worktree, when it is not used?
As in "git status". Now it works.
Another riddle was: if you can have work trees inside the git dir, why
are some programs complaining that they need a work tree?
IOW it is allowed to call
$ git --git-dir=../ --work-tree=. bla
when you really want to. In this case, you are both in the git directory
and in the working tree. So, programs have to actually test for the right
thing, namely if they are inside a working tree, and not if they are
inside a git directory.
Also, GIT_DIR=../.git should behave the same as if no GIT_DIR was
specified, unless there is a repository in the current working directory.
It does now.
The logic to determine if a repository is bare, or has a work tree
(tertium non datur), is this:
--work-tree=bla overrides GIT_WORK_TREE, which overrides core.bare = true,
which overrides core.worktree, which overrides GIT_DIR/.. when GIT_DIR
ends in /.git, which overrides the directory in which .git/ was found.
In related news, a long standing bug was fixed: when in .git/bla/x.git/,
which is a bare repository, git formerly assumed ../.. to be the
appropriate git dir. This problem was reported by Shawn Pearce to have
caused much pain, where a colleague mistakenly ran "git init" in "/" a
long time ago, and bare repositories just would not work.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-08-01 02:30:14 +02:00
|
|
|
/*
|
|
|
|
* We cannot decide in this function whether we are in the work tree or
|
|
|
|
* not, since the config can only be read _after_ this function was called.
|
|
|
|
*/
|
2010-08-06 04:46:33 +02:00
|
|
|
static const char *setup_git_directory_gently_1(int *nongit_ok)
|
2005-08-17 03:06:34 +02:00
|
|
|
{
|
2008-05-20 08:49:26 +02:00
|
|
|
const char *env_ceiling_dirs = getenv(CEILING_DIRECTORIES_ENVIRONMENT);
|
2012-10-28 17:16:24 +01:00
|
|
|
struct string_list ceiling_dirs = STRING_LIST_INIT_DUP;
|
2005-08-17 03:06:34 +02:00
|
|
|
static char cwd[PATH_MAX+1];
|
2010-11-26 16:32:38 +01:00
|
|
|
const char *gitdirenv, *ret;
|
|
|
|
char *gitfile;
|
2012-10-28 17:16:24 +01:00
|
|
|
int len, offset, offset_parent, ceil_offset = -1;
|
2010-07-13 11:02:00 +02:00
|
|
|
dev_t current_device = 0;
|
|
|
|
int one_filesystem = 1;
|
2005-08-17 03:06:34 +02:00
|
|
|
|
2008-03-25 22:06:26 +01:00
|
|
|
/*
|
|
|
|
* Let's assume that we are in a git repository.
|
|
|
|
* If it turns out later that we are somewhere else, the value will be
|
|
|
|
* updated accordingly.
|
|
|
|
*/
|
|
|
|
if (nongit_ok)
|
|
|
|
*nongit_ok = 0;
|
|
|
|
|
2010-11-26 16:32:39 +01:00
|
|
|
if (!getcwd(cwd, sizeof(cwd)-1))
|
|
|
|
die_errno("Unable to read current working directory");
|
|
|
|
offset = len = strlen(cwd);
|
|
|
|
|
Clean up work-tree handling
The old version of work-tree support was an unholy mess, barely readable,
and not to the point.
For example, why do you have to provide a worktree, when it is not used?
As in "git status". Now it works.
Another riddle was: if you can have work trees inside the git dir, why
are some programs complaining that they need a work tree?
IOW it is allowed to call
$ git --git-dir=../ --work-tree=. bla
when you really want to. In this case, you are both in the git directory
and in the working tree. So, programs have to actually test for the right
thing, namely if they are inside a working tree, and not if they are
inside a git directory.
Also, GIT_DIR=../.git should behave the same as if no GIT_DIR was
specified, unless there is a repository in the current working directory.
It does now.
The logic to determine if a repository is bare, or has a work tree
(tertium non datur), is this:
--work-tree=bla overrides GIT_WORK_TREE, which overrides core.bare = true,
which overrides core.worktree, which overrides GIT_DIR/.. when GIT_DIR
ends in /.git, which overrides the directory in which .git/ was found.
In related news, a long standing bug was fixed: when in .git/bla/x.git/,
which is a bare repository, git formerly assumed ../.. to be the
appropriate git dir. This problem was reported by Shawn Pearce to have
caused much pain, where a colleague mistakenly ran "git init" in "/" a
long time ago, and bare repositories just would not work.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-08-01 02:30:14 +02:00
|
|
|
/*
|
|
|
|
* If GIT_DIR is set explicitly, we're not going
|
|
|
|
* to do any discovery, but we still do repository
|
|
|
|
* validation.
|
|
|
|
*/
|
2006-12-31 05:30:19 +01:00
|
|
|
gitdirenv = getenv(GIT_DIR_ENVIRONMENT);
|
2010-07-24 13:19:44 +02:00
|
|
|
if (gitdirenv)
|
2010-11-26 16:32:39 +01:00
|
|
|
return setup_explicit_git_dir(gitdirenv, cwd, len, nongit_ok);
|
2005-08-17 03:06:34 +02:00
|
|
|
|
2012-10-28 17:16:24 +01:00
|
|
|
if (env_ceiling_dirs) {
|
Provide a mechanism to turn off symlink resolution in ceiling paths
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 <andersk@mit.edu>
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 <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-20 10:09:24 +01:00
|
|
|
int empty_entry_found = 0;
|
|
|
|
|
2012-10-28 17:16:24 +01:00
|
|
|
string_list_split(&ceiling_dirs, env_ceiling_dirs, PATH_SEP, -1);
|
2012-10-28 17:16:26 +01:00
|
|
|
filter_string_list(&ceiling_dirs, 0,
|
Provide a mechanism to turn off symlink resolution in ceiling paths
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 <andersk@mit.edu>
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 <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-20 10:09:24 +01:00
|
|
|
canonicalize_ceiling_entry, &empty_entry_found);
|
2012-10-28 17:16:24 +01:00
|
|
|
ceil_offset = longest_ancestor_length(cwd, &ceiling_dirs);
|
|
|
|
string_list_clear(&ceiling_dirs, 0);
|
|
|
|
}
|
|
|
|
|
2008-07-07 11:17:23 +02:00
|
|
|
if (ceil_offset < 0 && has_dos_drive_prefix(cwd))
|
|
|
|
ceil_offset = 1;
|
2005-08-17 03:06:34 +02:00
|
|
|
|
2007-06-06 09:10:42 +02:00
|
|
|
/*
|
Clean up work-tree handling
The old version of work-tree support was an unholy mess, barely readable,
and not to the point.
For example, why do you have to provide a worktree, when it is not used?
As in "git status". Now it works.
Another riddle was: if you can have work trees inside the git dir, why
are some programs complaining that they need a work tree?
IOW it is allowed to call
$ git --git-dir=../ --work-tree=. bla
when you really want to. In this case, you are both in the git directory
and in the working tree. So, programs have to actually test for the right
thing, namely if they are inside a working tree, and not if they are
inside a git directory.
Also, GIT_DIR=../.git should behave the same as if no GIT_DIR was
specified, unless there is a repository in the current working directory.
It does now.
The logic to determine if a repository is bare, or has a work tree
(tertium non datur), is this:
--work-tree=bla overrides GIT_WORK_TREE, which overrides core.bare = true,
which overrides core.worktree, which overrides GIT_DIR/.. when GIT_DIR
ends in /.git, which overrides the directory in which .git/ was found.
In related news, a long standing bug was fixed: when in .git/bla/x.git/,
which is a bare repository, git formerly assumed ../.. to be the
appropriate git dir. This problem was reported by Shawn Pearce to have
caused much pain, where a colleague mistakenly ran "git init" in "/" a
long time ago, and bare repositories just would not work.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-08-01 02:30:14 +02:00
|
|
|
* Test in the following order (relative to the cwd):
|
2008-02-20 23:13:13 +01:00
|
|
|
* - .git (file containing "gitdir: <path>")
|
Clean up work-tree handling
The old version of work-tree support was an unholy mess, barely readable,
and not to the point.
For example, why do you have to provide a worktree, when it is not used?
As in "git status". Now it works.
Another riddle was: if you can have work trees inside the git dir, why
are some programs complaining that they need a work tree?
IOW it is allowed to call
$ git --git-dir=../ --work-tree=. bla
when you really want to. In this case, you are both in the git directory
and in the working tree. So, programs have to actually test for the right
thing, namely if they are inside a working tree, and not if they are
inside a git directory.
Also, GIT_DIR=../.git should behave the same as if no GIT_DIR was
specified, unless there is a repository in the current working directory.
It does now.
The logic to determine if a repository is bare, or has a work tree
(tertium non datur), is this:
--work-tree=bla overrides GIT_WORK_TREE, which overrides core.bare = true,
which overrides core.worktree, which overrides GIT_DIR/.. when GIT_DIR
ends in /.git, which overrides the directory in which .git/ was found.
In related news, a long standing bug was fixed: when in .git/bla/x.git/,
which is a bare repository, git formerly assumed ../.. to be the
appropriate git dir. This problem was reported by Shawn Pearce to have
caused much pain, where a colleague mistakenly ran "git init" in "/" a
long time ago, and bare repositories just would not work.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-08-01 02:30:14 +02:00
|
|
|
* - .git/
|
|
|
|
* - ./ (bare)
|
2008-02-20 23:13:13 +01:00
|
|
|
* - ../.git
|
Clean up work-tree handling
The old version of work-tree support was an unholy mess, barely readable,
and not to the point.
For example, why do you have to provide a worktree, when it is not used?
As in "git status". Now it works.
Another riddle was: if you can have work trees inside the git dir, why
are some programs complaining that they need a work tree?
IOW it is allowed to call
$ git --git-dir=../ --work-tree=. bla
when you really want to. In this case, you are both in the git directory
and in the working tree. So, programs have to actually test for the right
thing, namely if they are inside a working tree, and not if they are
inside a git directory.
Also, GIT_DIR=../.git should behave the same as if no GIT_DIR was
specified, unless there is a repository in the current working directory.
It does now.
The logic to determine if a repository is bare, or has a work tree
(tertium non datur), is this:
--work-tree=bla overrides GIT_WORK_TREE, which overrides core.bare = true,
which overrides core.worktree, which overrides GIT_DIR/.. when GIT_DIR
ends in /.git, which overrides the directory in which .git/ was found.
In related news, a long standing bug was fixed: when in .git/bla/x.git/,
which is a bare repository, git formerly assumed ../.. to be the
appropriate git dir. This problem was reported by Shawn Pearce to have
caused much pain, where a colleague mistakenly ran "git init" in "/" a
long time ago, and bare repositories just would not work.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-08-01 02:30:14 +02:00
|
|
|
* - ../.git/
|
|
|
|
* - ../ (bare)
|
|
|
|
* - ../../.git/
|
|
|
|
* etc.
|
2007-06-06 09:10:42 +02:00
|
|
|
*/
|
2010-04-04 23:49:31 +02:00
|
|
|
one_filesystem = !git_env_bool("GIT_DISCOVERY_ACROSS_FILESYSTEM", 0);
|
2010-07-24 13:27:58 +02:00
|
|
|
if (one_filesystem)
|
2012-04-13 01:11:36 +02:00
|
|
|
current_device = get_device_or_die(".", NULL, 0);
|
Clean up work-tree handling
The old version of work-tree support was an unholy mess, barely readable,
and not to the point.
For example, why do you have to provide a worktree, when it is not used?
As in "git status". Now it works.
Another riddle was: if you can have work trees inside the git dir, why
are some programs complaining that they need a work tree?
IOW it is allowed to call
$ git --git-dir=../ --work-tree=. bla
when you really want to. In this case, you are both in the git directory
and in the working tree. So, programs have to actually test for the right
thing, namely if they are inside a working tree, and not if they are
inside a git directory.
Also, GIT_DIR=../.git should behave the same as if no GIT_DIR was
specified, unless there is a repository in the current working directory.
It does now.
The logic to determine if a repository is bare, or has a work tree
(tertium non datur), is this:
--work-tree=bla overrides GIT_WORK_TREE, which overrides core.bare = true,
which overrides core.worktree, which overrides GIT_DIR/.. when GIT_DIR
ends in /.git, which overrides the directory in which .git/ was found.
In related news, a long standing bug was fixed: when in .git/bla/x.git/,
which is a bare repository, git formerly assumed ../.. to be the
appropriate git dir. This problem was reported by Shawn Pearce to have
caused much pain, where a colleague mistakenly ran "git init" in "/" a
long time ago, and bare repositories just would not work.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-08-01 02:30:14 +02:00
|
|
|
for (;;) {
|
2011-08-22 23:04:56 +02:00
|
|
|
gitfile = (char*)read_gitfile(DEFAULT_GIT_DIR_ENVIRONMENT);
|
2010-11-26 16:32:38 +01:00
|
|
|
if (gitfile)
|
|
|
|
gitdirenv = gitfile = xstrdup(gitfile);
|
|
|
|
else {
|
|
|
|
if (is_git_directory(DEFAULT_GIT_DIR_ENVIRONMENT))
|
|
|
|
gitdirenv = DEFAULT_GIT_DIR_ENVIRONMENT;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (gitdirenv) {
|
|
|
|
ret = setup_discovered_git_dir(gitdirenv,
|
|
|
|
cwd, offset, len,
|
|
|
|
nongit_ok);
|
|
|
|
free(gitfile);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
free(gitfile);
|
|
|
|
|
2010-07-24 13:25:32 +02:00
|
|
|
if (is_git_directory("."))
|
2010-11-26 16:32:36 +01:00
|
|
|
return setup_bare_git_dir(cwd, offset, len, nongit_ok);
|
|
|
|
|
2012-04-13 01:11:36 +02:00
|
|
|
offset_parent = offset;
|
|
|
|
while (--offset_parent > ceil_offset && cwd[offset_parent] != '/');
|
|
|
|
if (offset_parent <= ceil_offset)
|
2010-07-24 13:26:41 +02:00
|
|
|
return setup_nongit(cwd, nongit_ok);
|
2010-03-17 20:55:53 +01:00
|
|
|
if (one_filesystem) {
|
2012-04-13 01:11:36 +02:00
|
|
|
dev_t parent_device = get_device_or_die("..", cwd, offset);
|
2010-07-24 13:27:58 +02:00
|
|
|
if (parent_device != current_device) {
|
2010-03-17 20:55:53 +01:00
|
|
|
if (nongit_ok) {
|
|
|
|
if (chdir(cwd))
|
|
|
|
die_errno("Cannot come back to cwd");
|
|
|
|
*nongit_ok = 1;
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
cwd[offset] = '\0';
|
2012-04-13 01:11:36 +02:00
|
|
|
die("Not a git repository (or any parent up to mount point %s)\n"
|
2010-04-04 23:49:31 +02:00
|
|
|
"Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).", cwd);
|
2010-03-17 20:55:53 +01:00
|
|
|
}
|
|
|
|
}
|
2010-03-17 20:55:52 +01:00
|
|
|
if (chdir("..")) {
|
|
|
|
cwd[offset] = '\0';
|
2009-06-27 17:58:46 +02:00
|
|
|
die_errno("Cannot change to '%s/..'", cwd);
|
2010-03-17 20:55:52 +01:00
|
|
|
}
|
2012-04-13 01:11:36 +02:00
|
|
|
offset = offset_parent;
|
2007-06-06 09:10:42 +02:00
|
|
|
}
|
2005-08-17 03:06:34 +02:00
|
|
|
}
|
2005-11-26 00:43:41 +01:00
|
|
|
|
2010-08-06 04:46:33 +02:00
|
|
|
const char *setup_git_directory_gently(int *nongit_ok)
|
|
|
|
{
|
|
|
|
const char *prefix;
|
|
|
|
|
|
|
|
prefix = setup_git_directory_gently_1(nongit_ok);
|
2011-05-26 05:37:12 +02:00
|
|
|
if (prefix)
|
2013-03-08 10:30:25 +01:00
|
|
|
setenv(GIT_PREFIX_ENVIRONMENT, prefix, 1);
|
2011-05-26 05:37:12 +02:00
|
|
|
else
|
2013-03-08 10:30:25 +01:00
|
|
|
setenv(GIT_PREFIX_ENVIRONMENT, "", 1);
|
2011-05-26 05:37:12 +02:00
|
|
|
|
2010-12-02 00:33:22 +01:00
|
|
|
if (startup_info) {
|
2010-08-06 04:46:33 +02:00
|
|
|
startup_info->have_repository = !nongit_ok || !*nongit_ok;
|
2010-12-02 00:33:22 +01:00
|
|
|
startup_info->prefix = prefix;
|
|
|
|
}
|
2010-08-06 04:46:33 +02:00
|
|
|
return prefix;
|
|
|
|
}
|
|
|
|
|
2006-06-10 08:09:49 +02:00
|
|
|
int git_config_perm(const char *var, const char *value)
|
|
|
|
{
|
2008-04-16 10:34:24 +02:00
|
|
|
int i;
|
|
|
|
char *endptr;
|
|
|
|
|
|
|
|
if (value == NULL)
|
|
|
|
return PERM_GROUP;
|
|
|
|
|
|
|
|
if (!strcmp(value, "umask"))
|
|
|
|
return PERM_UMASK;
|
|
|
|
if (!strcmp(value, "group"))
|
|
|
|
return PERM_GROUP;
|
|
|
|
if (!strcmp(value, "all") ||
|
|
|
|
!strcmp(value, "world") ||
|
|
|
|
!strcmp(value, "everybody"))
|
|
|
|
return PERM_EVERYBODY;
|
|
|
|
|
|
|
|
/* Parse octal numbers */
|
|
|
|
i = strtol(value, &endptr, 8);
|
|
|
|
|
|
|
|
/* If not an octal number, maybe true/false? */
|
|
|
|
if (*endptr != 0)
|
|
|
|
return git_config_bool(var, value) ? PERM_GROUP : PERM_UMASK;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Treat values 0, 1 and 2 as compatibility cases, otherwise it is
|
2009-03-26 00:19:36 +01:00
|
|
|
* a chmod value to restrict to.
|
2008-04-16 10:34:24 +02:00
|
|
|
*/
|
|
|
|
switch (i) {
|
|
|
|
case PERM_UMASK: /* 0 */
|
|
|
|
return PERM_UMASK;
|
|
|
|
case OLD_PERM_GROUP: /* 1 */
|
|
|
|
return PERM_GROUP;
|
|
|
|
case OLD_PERM_EVERYBODY: /* 2 */
|
|
|
|
return PERM_EVERYBODY;
|
2006-06-10 08:09:49 +02:00
|
|
|
}
|
2008-04-16 10:34:24 +02:00
|
|
|
|
|
|
|
/* A filemode value was given: 0xxx */
|
|
|
|
|
|
|
|
if ((i & 0600) != 0600)
|
|
|
|
die("Problem with core.sharedRepository filemode value "
|
|
|
|
"(0%.3o).\nThe owner of files must always have "
|
|
|
|
"read and write permissions.", i);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Mask filemode value. Others can not get write permission.
|
|
|
|
* x flags for directories are handled separately.
|
|
|
|
*/
|
2009-03-26 00:19:36 +01:00
|
|
|
return -(i & 0666);
|
2006-06-10 08:09:49 +02:00
|
|
|
}
|
|
|
|
|
2008-05-14 19:46:53 +02:00
|
|
|
int check_repository_format_version(const char *var, const char *value, void *cb)
|
2005-11-26 00:59:09 +01:00
|
|
|
{
|
2007-07-30 01:24:38 +02:00
|
|
|
if (strcmp(var, "core.repositoryformatversion") == 0)
|
|
|
|
repository_format_version = git_config_int(var, value);
|
2005-12-22 23:13:56 +01:00
|
|
|
else if (strcmp(var, "core.sharedrepository") == 0)
|
2006-06-10 08:09:49 +02:00
|
|
|
shared_repository = git_config_perm(var, value);
|
Clean up work-tree handling
The old version of work-tree support was an unholy mess, barely readable,
and not to the point.
For example, why do you have to provide a worktree, when it is not used?
As in "git status". Now it works.
Another riddle was: if you can have work trees inside the git dir, why
are some programs complaining that they need a work tree?
IOW it is allowed to call
$ git --git-dir=../ --work-tree=. bla
when you really want to. In this case, you are both in the git directory
and in the working tree. So, programs have to actually test for the right
thing, namely if they are inside a working tree, and not if they are
inside a git directory.
Also, GIT_DIR=../.git should behave the same as if no GIT_DIR was
specified, unless there is a repository in the current working directory.
It does now.
The logic to determine if a repository is bare, or has a work tree
(tertium non datur), is this:
--work-tree=bla overrides GIT_WORK_TREE, which overrides core.bare = true,
which overrides core.worktree, which overrides GIT_DIR/.. when GIT_DIR
ends in /.git, which overrides the directory in which .git/ was found.
In related news, a long standing bug was fixed: when in .git/bla/x.git/,
which is a bare repository, git formerly assumed ../.. to be the
appropriate git dir. This problem was reported by Shawn Pearce to have
caused much pain, where a colleague mistakenly ran "git init" in "/" a
long time ago, and bare repositories just would not work.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-08-01 02:30:14 +02:00
|
|
|
else if (strcmp(var, "core.bare") == 0) {
|
|
|
|
is_bare_repository_cfg = git_config_bool(var, value);
|
|
|
|
if (is_bare_repository_cfg == 1)
|
|
|
|
inside_work_tree = -1;
|
|
|
|
} else if (strcmp(var, "core.worktree") == 0) {
|
2008-02-11 20:00:32 +01:00
|
|
|
if (!value)
|
|
|
|
return config_error_nonbool(var);
|
Avoid unnecessary "if-before-free" tests.
This change removes all obvious useless if-before-free tests.
E.g., it replaces code like this:
if (some_expression)
free (some_expression);
with the now-equivalent:
free (some_expression);
It is equivalent not just because POSIX has required free(NULL)
to work for a long time, but simply because it has worked for
so long that no reasonable porting target fails the test.
Here's some evidence from nearly 1.5 years ago:
http://www.winehq.org/pipermail/wine-patches/2006-October/031544.html
FYI, the change below was prepared by running the following:
git ls-files -z | xargs -0 \
perl -0x3b -pi -e \
's/\bif\s*\(\s*(\S+?)(?:\s*!=\s*NULL)?\s*\)\s+(free\s*\(\s*\1\s*\))/$2/s'
Note however, that it doesn't handle brace-enclosed blocks like
"if (x) { free (x); }". But that's ok, since there were none like
that in git sources.
Beware: if you do use the above snippet, note that it can
produce syntactically invalid C code. That happens when the
affected "if"-statement has a matching "else".
E.g., it would transform this
if (x)
free (x);
else
foo ();
into this:
free (x);
else
foo ();
There were none of those here, either.
If you're interested in automating detection of the useless
tests, you might like the useless-if-before-free script in gnulib:
[it *does* detect brace-enclosed free statements, and has a --name=S
option to make it detect free-like functions with different names]
http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=blob;f=build-aux/useless-if-before-free
Addendum:
Remove one more (in imap-send.c), spotted by Jean-Luc Herren <jlh@gmx.ch>.
Signed-off-by: Jim Meyering <meyering@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-01-31 18:26:32 +01:00
|
|
|
free(git_work_tree_cfg);
|
Clean up work-tree handling
The old version of work-tree support was an unholy mess, barely readable,
and not to the point.
For example, why do you have to provide a worktree, when it is not used?
As in "git status". Now it works.
Another riddle was: if you can have work trees inside the git dir, why
are some programs complaining that they need a work tree?
IOW it is allowed to call
$ git --git-dir=../ --work-tree=. bla
when you really want to. In this case, you are both in the git directory
and in the working tree. So, programs have to actually test for the right
thing, namely if they are inside a working tree, and not if they are
inside a git directory.
Also, GIT_DIR=../.git should behave the same as if no GIT_DIR was
specified, unless there is a repository in the current working directory.
It does now.
The logic to determine if a repository is bare, or has a work tree
(tertium non datur), is this:
--work-tree=bla overrides GIT_WORK_TREE, which overrides core.bare = true,
which overrides core.worktree, which overrides GIT_DIR/.. when GIT_DIR
ends in /.git, which overrides the directory in which .git/ was found.
In related news, a long standing bug was fixed: when in .git/bla/x.git/,
which is a bare repository, git formerly assumed ../.. to be the
appropriate git dir. This problem was reported by Shawn Pearce to have
caused much pain, where a colleague mistakenly ran "git init" in "/" a
long time ago, and bare repositories just would not work.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-08-01 02:30:14 +02:00
|
|
|
git_work_tree_cfg = xstrdup(value);
|
|
|
|
inside_work_tree = -1;
|
|
|
|
}
|
2007-07-30 01:24:38 +02:00
|
|
|
return 0;
|
2005-11-26 00:59:09 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
int check_repository_format(void)
|
|
|
|
{
|
2010-11-26 16:32:34 +01:00
|
|
|
return check_repository_format_gently(get_git_dir(), NULL);
|
2005-11-26 00:59:09 +01:00
|
|
|
}
|
|
|
|
|
2010-06-05 10:04:20 +02:00
|
|
|
/*
|
|
|
|
* Returns the "prefix", a path to the current working directory
|
|
|
|
* relative to the work tree root, or NULL, if the current working
|
|
|
|
* directory is not a strict subdirectory of the work tree root. The
|
|
|
|
* prefix always ends with a '/' character.
|
|
|
|
*/
|
2005-11-26 00:43:41 +01:00
|
|
|
const char *setup_git_directory(void)
|
|
|
|
{
|
2010-11-26 16:32:39 +01:00
|
|
|
return setup_git_directory_gently(NULL);
|
2005-11-26 00:43:41 +01:00
|
|
|
}
|
2011-08-15 23:17:46 +02:00
|
|
|
|
|
|
|
const char *resolve_gitdir(const char *suspect)
|
|
|
|
{
|
|
|
|
if (is_git_directory(suspect))
|
|
|
|
return suspect;
|
2011-10-11 00:56:16 +02:00
|
|
|
return read_gitfile(suspect);
|
2011-08-15 23:17:46 +02:00
|
|
|
}
|