2005-08-17 01:06:34 +00: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 00:30:14 +00:00
|
|
|
#include "dir.h"
|
|
|
|
|
|
|
|
static int inside_git_dir = -1;
|
|
|
|
static int inside_work_tree = -1;
|
2005-08-17 01:06:34 +00:00
|
|
|
|
2005-09-21 07:00:47 +00:00
|
|
|
const char *prefix_path(const char *prefix, int len, const char *path)
|
2005-08-17 03:44:32 +00:00
|
|
|
{
|
2005-09-21 07:00:47 +00:00
|
|
|
const char *orig = path;
|
2005-08-17 03:44:32 +00:00
|
|
|
for (;;) {
|
|
|
|
char c;
|
|
|
|
if (*path != '.')
|
|
|
|
break;
|
|
|
|
c = path[1];
|
|
|
|
/* "." */
|
|
|
|
if (!c) {
|
|
|
|
path++;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
/* "./" */
|
|
|
|
if (c == '/') {
|
|
|
|
path += 2;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (c != '.')
|
|
|
|
break;
|
|
|
|
c = path[2];
|
|
|
|
if (!c)
|
|
|
|
path += 2;
|
|
|
|
else if (c == '/')
|
|
|
|
path += 3;
|
|
|
|
else
|
|
|
|
break;
|
|
|
|
/* ".." and "../" */
|
|
|
|
/* Remove last component of the prefix */
|
|
|
|
do {
|
|
|
|
if (!len)
|
|
|
|
die("'%s' is outside repository", orig);
|
|
|
|
len--;
|
|
|
|
} while (len && prefix[len-1] != '/');
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (len) {
|
|
|
|
int speclen = strlen(path);
|
|
|
|
char *n = xmalloc(speclen + len + 1);
|
2007-06-07 07:04:01 +00:00
|
|
|
|
2005-08-17 03:44:32 +00:00
|
|
|
memcpy(n, prefix, len);
|
|
|
|
memcpy(n + len, path, speclen+1);
|
|
|
|
path = n;
|
|
|
|
}
|
|
|
|
return path;
|
|
|
|
}
|
|
|
|
|
2007-06-07 07:04:01 +00:00
|
|
|
/*
|
2005-11-26 07:14:15 +00:00
|
|
|
* Unlike prefix_path, this should be used if the named file does
|
|
|
|
* not have to interact with index entry; i.e. name of a random file
|
|
|
|
* on the filesystem.
|
|
|
|
*/
|
|
|
|
const char *prefix_filename(const char *pfx, int pfx_len, const char *arg)
|
|
|
|
{
|
|
|
|
static char path[PATH_MAX];
|
|
|
|
if (!pfx || !*pfx || arg[0] == '/')
|
|
|
|
return arg;
|
|
|
|
memcpy(path, pfx, pfx_len);
|
|
|
|
strcpy(path + pfx_len, arg);
|
|
|
|
return path;
|
|
|
|
}
|
|
|
|
|
2006-04-26 17:15:54 +00: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")
|
|
|
|
*/
|
|
|
|
void verify_filename(const char *prefix, const char *arg)
|
|
|
|
{
|
|
|
|
const char *name;
|
|
|
|
struct stat st;
|
|
|
|
|
|
|
|
if (*arg == '-')
|
|
|
|
die("bad flag '%s' used after filename", arg);
|
|
|
|
name = prefix ? prefix_filename(prefix, strlen(prefix), arg) : arg;
|
|
|
|
if (!lstat(name, &st))
|
|
|
|
return;
|
|
|
|
if (errno == ENOENT)
|
2006-04-26 22:09:27 +00:00
|
|
|
die("ambiguous argument '%s': unknown revision or path not in the working tree.\n"
|
|
|
|
"Use '--' to separate paths from revisions", arg);
|
2006-04-26 17:15:54 +00:00
|
|
|
die("'%s': %s", arg, strerror(errno));
|
|
|
|
}
|
|
|
|
|
2006-04-26 22:09:27 +00: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)
|
|
|
|
{
|
|
|
|
const char *name;
|
|
|
|
struct stat st;
|
|
|
|
|
2007-06-03 14:48:16 +00:00
|
|
|
if (!is_inside_work_tree() || is_inside_git_dir())
|
2007-01-20 02:09:34 +00:00
|
|
|
return;
|
2006-04-26 22:09:27 +00:00
|
|
|
if (*arg == '-')
|
|
|
|
return; /* flag */
|
|
|
|
name = prefix ? prefix_filename(prefix, strlen(prefix), arg) : arg;
|
|
|
|
if (!lstat(name, &st))
|
|
|
|
die("ambiguous argument '%s': both revision and filename\n"
|
|
|
|
"Use '--' to separate filenames from revisions", arg);
|
2007-08-06 07:20:06 +00:00
|
|
|
if (errno != ENOENT && errno != ENOTDIR)
|
2006-04-26 22:09:27 +00:00
|
|
|
die("'%s': %s", arg, strerror(errno));
|
|
|
|
}
|
|
|
|
|
2005-09-21 07:00:47 +00:00
|
|
|
const char **get_pathspec(const char *prefix, const char **pathspec)
|
2005-08-17 01:06:34 +00:00
|
|
|
{
|
2005-09-21 07:00:47 +00:00
|
|
|
const char *entry = *pathspec;
|
|
|
|
const char **p;
|
2005-08-17 01:06:34 +00:00
|
|
|
int prefixlen;
|
|
|
|
|
2005-08-17 03:44:32 +00:00
|
|
|
if (!prefix && !entry)
|
|
|
|
return NULL;
|
2005-08-17 01:06:34 +00:00
|
|
|
|
|
|
|
if (!entry) {
|
|
|
|
static const char *spec[2];
|
|
|
|
spec[0] = prefix;
|
|
|
|
spec[1] = NULL;
|
|
|
|
return spec;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Otherwise we have to re-write the entries.. */
|
|
|
|
p = pathspec;
|
2005-08-17 03:44:32 +00:00
|
|
|
prefixlen = prefix ? strlen(prefix) : 0;
|
2005-08-17 01:06:34 +00:00
|
|
|
do {
|
2005-08-17 03:44:32 +00:00
|
|
|
*p = prefix_path(prefix, prefixlen, entry);
|
2005-08-17 01:06:34 +00:00
|
|
|
} while ((entry = *++p) != NULL);
|
|
|
|
return (const char **) pathspec;
|
|
|
|
}
|
|
|
|
|
[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 20:54:42 +00:00
|
|
|
/*
|
2006-12-31 04:30:19 +00:00
|
|
|
* Test if it looks like we're at a git directory.
|
2005-11-25 23:43:41 +00: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 20:54:42 +00:00
|
|
|
*
|
2006-12-31 04:30:19 +00:00
|
|
|
* - either a 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 20:54:42 +00:00
|
|
|
* GIT_OBJECT_DIRECTORY environment variable
|
2006-12-31 04:30:19 +00:00
|
|
|
* - a refs/ directory
|
2005-09-30 21:26:57 +00:00
|
|
|
* - either a HEAD symlink or a HEAD file that is formatted as
|
2007-01-02 07:31:08 +00: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 20:54:42 +00:00
|
|
|
*/
|
2006-12-31 04:30:19 +00:00
|
|
|
static 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 20:54:42 +00:00
|
|
|
{
|
2006-12-31 04:30:19 +00:00
|
|
|
char path[PATH_MAX];
|
|
|
|
size_t len = strlen(suspect);
|
|
|
|
|
|
|
|
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 21:26:57 +00:00
|
|
|
return 0;
|
2006-12-31 04:30:19 +00:00
|
|
|
|
|
|
|
strcpy(path + len, "/HEAD");
|
2007-01-02 07:31:08 +00:00
|
|
|
if (validate_headref(path))
|
2006-12-31 04:30:19 +00:00
|
|
|
return 0;
|
|
|
|
|
2005-09-30 21:26:57 +00: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 20:54:42 +00:00
|
|
|
}
|
|
|
|
|
2007-01-20 02:09:34 +00: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 00:30:14 +00:00
|
|
|
if (inside_git_dir < 0)
|
|
|
|
inside_git_dir = is_inside_dir(get_git_dir());
|
|
|
|
return inside_git_dir;
|
2007-06-06 07:10:42 +00: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 00:30:14 +00:00
|
|
|
if (inside_work_tree < 0)
|
|
|
|
inside_work_tree = is_inside_dir(get_git_work_tree());
|
|
|
|
return inside_work_tree;
|
2007-06-06 07:10:42 +00: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 00:30:14 +00:00
|
|
|
/*
|
2007-08-05 13:12:53 +00:00
|
|
|
* set_work_tree() is only ever called if you set GIT_DIR explicitely.
|
|
|
|
* The old behaviour (which we retain here) is to set the work tree root
|
|
|
|
* to the cwd, unless overridden by the config, the command line, or
|
|
|
|
* GIT_WORK_TREE.
|
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 00:30:14 +00:00
|
|
|
*/
|
2007-08-05 13:12:53 +00:00
|
|
|
static const char *set_work_tree(const char *dir)
|
2007-06-06 07:10:42 +00:00
|
|
|
{
|
2007-08-05 13:12:53 +00:00
|
|
|
char buffer[PATH_MAX + 1];
|
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 00:30:14 +00:00
|
|
|
|
2007-08-05 13:12:53 +00:00
|
|
|
if (!getcwd(buffer, sizeof(buffer)))
|
|
|
|
die ("Could not get the current working directory");
|
|
|
|
git_work_tree_cfg = xstrdup(buffer);
|
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 00:30:14 +00:00
|
|
|
inside_work_tree = 1;
|
|
|
|
|
2007-08-05 13:12:53 +00:00
|
|
|
return NULL;
|
2007-01-20 02:09:34 +00:00
|
|
|
}
|
|
|
|
|
2007-11-08 23:35:32 +00:00
|
|
|
void setup_work_tree(void)
|
|
|
|
{
|
2007-11-09 11:34:07 +00: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 11:23:11 +00:00
|
|
|
if (!is_absolute_path(git_dir))
|
|
|
|
set_git_dir(make_absolute_path(git_dir));
|
|
|
|
if (!work_tree || chdir(work_tree))
|
|
|
|
die("This operation must be run in a work tree");
|
2007-11-09 11:34:07 +00:00
|
|
|
initialized = 1;
|
2007-11-03 11:23:11 +00: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 00:30:14 +00: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.
|
|
|
|
*/
|
2005-11-26 07:14:15 +00:00
|
|
|
const char *setup_git_directory_gently(int *nongit_ok)
|
2005-08-17 01:06:34 +00: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 00:30:14 +00:00
|
|
|
const char *work_tree_env = getenv(GIT_WORK_TREE_ENVIRONMENT);
|
2005-08-17 01:06:34 +00:00
|
|
|
static char cwd[PATH_MAX+1];
|
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 00:30:14 +00:00
|
|
|
const char *gitdirenv;
|
|
|
|
int len, offset;
|
2005-08-17 01:06:34 +00: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 00:30:14 +00:00
|
|
|
/*
|
|
|
|
* If GIT_DIR is set explicitly, we're not going
|
|
|
|
* to do any discovery, but we still do repository
|
|
|
|
* validation.
|
|
|
|
*/
|
2006-12-31 04:30:19 +00:00
|
|
|
gitdirenv = getenv(GIT_DIR_ENVIRONMENT);
|
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 00:30:14 +00:00
|
|
|
if (gitdirenv) {
|
|
|
|
if (PATH_MAX - 40 < strlen(gitdirenv))
|
|
|
|
die("'$%s' too big", GIT_DIR_ENVIRONMENT);
|
|
|
|
if (is_git_directory(gitdirenv)) {
|
2007-10-16 23:37:36 +00:00
|
|
|
static char buffer[1024 + 1];
|
|
|
|
const char *retval;
|
|
|
|
|
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 00:30:14 +00:00
|
|
|
if (!work_tree_env)
|
|
|
|
return set_work_tree(gitdirenv);
|
2007-10-16 23:37:36 +00:00
|
|
|
retval = get_relative_cwd(buffer, sizeof(buffer) - 1,
|
|
|
|
get_git_work_tree());
|
|
|
|
if (!retval || !*retval)
|
|
|
|
return NULL;
|
|
|
|
set_git_dir(make_absolute_path(gitdirenv));
|
|
|
|
if (chdir(work_tree_env) < 0)
|
|
|
|
die ("Could not chdir to %s", work_tree_env);
|
|
|
|
strcat(buffer, "/");
|
|
|
|
return retval;
|
2007-06-06 07:10:42 +00:00
|
|
|
}
|
2006-08-04 15:46:19 +00:00
|
|
|
if (nongit_ok) {
|
2006-07-30 01:30:29 +00:00
|
|
|
*nongit_ok = 1;
|
|
|
|
return NULL;
|
|
|
|
}
|
2006-12-31 04:30:19 +00:00
|
|
|
die("Not a git repository: '%s'", gitdirenv);
|
2005-11-25 23:43:41 +00:00
|
|
|
}
|
2005-08-17 01:06:34 +00:00
|
|
|
|
2007-07-04 19:45:42 +00:00
|
|
|
if (!getcwd(cwd, sizeof(cwd)-1))
|
2005-08-17 01:06:34 +00:00
|
|
|
die("Unable to read current working directory");
|
|
|
|
|
2007-06-06 07:10:42 +00: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 00:30:14 +00:00
|
|
|
* Test in the following order (relative to the cwd):
|
|
|
|
* - .git/
|
|
|
|
* - ./ (bare)
|
|
|
|
* - ../.git/
|
|
|
|
* - ../ (bare)
|
|
|
|
* - ../../.git/
|
|
|
|
* etc.
|
2007-06-06 07:10:42 +00: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 00:30:14 +00:00
|
|
|
offset = len = strlen(cwd);
|
|
|
|
for (;;) {
|
|
|
|
if (is_git_directory(DEFAULT_GIT_DIR_ENVIRONMENT))
|
|
|
|
break;
|
|
|
|
if (is_git_directory(".")) {
|
|
|
|
inside_git_dir = 1;
|
|
|
|
if (!work_tree_env)
|
|
|
|
inside_work_tree = 0;
|
|
|
|
setenv(GIT_DIR_ENVIRONMENT, ".", 1);
|
2007-06-06 07:10:42 +00:00
|
|
|
return NULL;
|
|
|
|
}
|
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 00:30:14 +00:00
|
|
|
chdir("..");
|
|
|
|
do {
|
|
|
|
if (!offset) {
|
|
|
|
if (nongit_ok) {
|
|
|
|
if (chdir(cwd))
|
|
|
|
die("Cannot come back to cwd");
|
|
|
|
*nongit_ok = 1;
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
die("Not a git repository");
|
|
|
|
}
|
|
|
|
} while (cwd[--offset] != '/');
|
2007-06-06 07:10:42 +00: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 00:30:14 +00:00
|
|
|
inside_git_dir = 0;
|
|
|
|
if (!work_tree_env)
|
|
|
|
inside_work_tree = 1;
|
|
|
|
git_work_tree_cfg = xstrndup(cwd, offset);
|
|
|
|
if (offset == len)
|
2005-08-17 01:06:34 +00:00
|
|
|
return NULL;
|
|
|
|
|
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 00:30:14 +00:00
|
|
|
/* Make "offset" point to past the '/', and add a '/' at the end */
|
|
|
|
offset++;
|
|
|
|
cwd[len++] = '/';
|
|
|
|
cwd[len] = 0;
|
|
|
|
return cwd + offset;
|
2005-08-17 01:06:34 +00:00
|
|
|
}
|
2005-11-25 23:43:41 +00:00
|
|
|
|
2006-06-10 06:09:49 +00:00
|
|
|
int git_config_perm(const char *var, const char *value)
|
|
|
|
{
|
|
|
|
if (value) {
|
2007-07-11 14:18:17 +00:00
|
|
|
int i;
|
2006-06-10 06:09:49 +00:00
|
|
|
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;
|
2007-07-11 14:18:17 +00:00
|
|
|
i = atoi(value);
|
|
|
|
if (i > 1)
|
|
|
|
return i;
|
2006-06-10 06:09:49 +00:00
|
|
|
}
|
|
|
|
return git_config_bool(var, value);
|
|
|
|
}
|
|
|
|
|
2005-11-25 23:59:09 +00:00
|
|
|
int check_repository_format_version(const char *var, const char *value)
|
|
|
|
{
|
2007-07-29 23:24:38 +00:00
|
|
|
if (strcmp(var, "core.repositoryformatversion") == 0)
|
|
|
|
repository_format_version = git_config_int(var, value);
|
2005-12-22 22:13:56 +00:00
|
|
|
else if (strcmp(var, "core.sharedrepository") == 0)
|
2006-06-10 06:09:49 +00: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 00:30:14 +00: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) {
|
|
|
|
if (git_work_tree_cfg)
|
|
|
|
free(git_work_tree_cfg);
|
|
|
|
git_work_tree_cfg = xstrdup(value);
|
|
|
|
inside_work_tree = -1;
|
|
|
|
}
|
2007-07-29 23:24:38 +00:00
|
|
|
return 0;
|
2005-11-25 23:59:09 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
int check_repository_format(void)
|
|
|
|
{
|
|
|
|
git_config(check_repository_format_version);
|
|
|
|
if (GIT_REPO_VERSION < repository_format_version)
|
|
|
|
die ("Expected git repo version <= %d, found %d",
|
|
|
|
GIT_REPO_VERSION, repository_format_version);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2005-11-25 23:43:41 +00:00
|
|
|
const char *setup_git_directory(void)
|
|
|
|
{
|
2005-11-26 07:14:15 +00:00
|
|
|
const char *retval = setup_git_directory_gently(NULL);
|
2005-11-26 00:08:48 +00:00
|
|
|
check_repository_format();
|
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 00:30:14 +00:00
|
|
|
|
|
|
|
/* If the work tree is not the default one, recompute prefix */
|
|
|
|
if (inside_work_tree < 0) {
|
|
|
|
static char buffer[PATH_MAX + 1];
|
|
|
|
char *rel;
|
|
|
|
if (retval && chdir(retval))
|
|
|
|
die ("Could not jump back into original cwd");
|
|
|
|
rel = get_relative_cwd(buffer, PATH_MAX, get_git_work_tree());
|
|
|
|
return rel && *rel ? strcat(rel, "/") : NULL;
|
|
|
|
}
|
|
|
|
|
2005-11-25 23:43:41 +00:00
|
|
|
return retval;
|
|
|
|
}
|