|
|
|
#!/bin/sh
|
|
|
|
|
|
|
|
test_description='test separate work tree'
|
|
|
|
. ./test-lib.sh
|
|
|
|
|
|
|
|
test_rev_parse() {
|
|
|
|
name=$1
|
|
|
|
shift
|
|
|
|
|
|
|
|
test_expect_success "$name: is-bare-repository" \
|
|
|
|
"test '$1' = \"\$(git rev-parse --is-bare-repository)\""
|
|
|
|
shift
|
|
|
|
[ $# -eq 0 ] && return
|
|
|
|
|
|
|
|
test_expect_success "$name: is-inside-git-dir" \
|
|
|
|
"test '$1' = \"\$(git rev-parse --is-inside-git-dir)\""
|
|
|
|
shift
|
|
|
|
[ $# -eq 0 ] && return
|
|
|
|
|
|
|
|
test_expect_success "$name: is-inside-work-tree" \
|
|
|
|
"test '$1' = \"\$(git rev-parse --is-inside-work-tree)\""
|
|
|
|
shift
|
|
|
|
[ $# -eq 0 ] && return
|
|
|
|
|
|
|
|
test_expect_success "$name: prefix" \
|
|
|
|
"test '$1' = \"\$(git rev-parse --show-prefix)\""
|
|
|
|
shift
|
|
|
|
[ $# -eq 0 ] && return
|
|
|
|
}
|
|
|
|
|
|
|
|
mkdir -p work/sub/dir || exit 1
|
|
|
|
mv .git repo.git || exit 1
|
|
|
|
|
|
|
|
say "core.worktree = relative path"
|
|
|
|
export GIT_DIR=repo.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>
18 years ago
|
|
|
export GIT_CONFIG="$(pwd)"/$GIT_DIR/config
|
|
|
|
unset GIT_WORK_TREE
|
|
|
|
git config core.worktree ../work
|
|
|
|
test_rev_parse 'outside' false false false
|
|
|
|
cd work || exit 1
|
|
|
|
export GIT_DIR=../repo.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>
18 years ago
|
|
|
export GIT_CONFIG="$(pwd)"/$GIT_DIR/config
|
|
|
|
test_rev_parse 'inside' false false true ''
|
|
|
|
cd sub/dir || exit 1
|
|
|
|
export GIT_DIR=../../../repo.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>
18 years ago
|
|
|
export GIT_CONFIG="$(pwd)"/$GIT_DIR/config
|
|
|
|
test_rev_parse 'subdirectory' false false true sub/dir/
|
|
|
|
cd ../../.. || exit 1
|
|
|
|
|
|
|
|
say "core.worktree = absolute path"
|
|
|
|
export GIT_DIR=$(pwd)/repo.git
|
|
|
|
export GIT_CONFIG=$GIT_DIR/config
|
|
|
|
git config core.worktree "$(pwd)/work"
|
|
|
|
test_rev_parse 'outside' false false false
|
|
|
|
cd work || exit 1
|
|
|
|
test_rev_parse 'inside' false false true ''
|
|
|
|
cd sub/dir || exit 1
|
|
|
|
test_rev_parse 'subdirectory' false false true sub/dir/
|
|
|
|
cd ../../.. || exit 1
|
|
|
|
|
|
|
|
say "GIT_WORK_TREE=relative path (override core.worktree)"
|
|
|
|
export GIT_DIR=$(pwd)/repo.git
|
|
|
|
export GIT_CONFIG=$GIT_DIR/config
|
|
|
|
git config core.worktree non-existent
|
|
|
|
export GIT_WORK_TREE=work
|
|
|
|
test_rev_parse 'outside' false false false
|
|
|
|
cd work || exit 1
|
|
|
|
export GIT_WORK_TREE=.
|
|
|
|
test_rev_parse 'inside' false false true ''
|
|
|
|
cd sub/dir || exit 1
|
|
|
|
export GIT_WORK_TREE=../..
|
|
|
|
test_rev_parse 'subdirectory' false false true sub/dir/
|
|
|
|
cd ../../.. || exit 1
|
|
|
|
|
|
|
|
mv work repo.git/work
|
|
|
|
|
|
|
|
say "GIT_WORK_TREE=absolute path, work tree below git dir"
|
|
|
|
export GIT_DIR=$(pwd)/repo.git
|
|
|
|
export GIT_CONFIG=$GIT_DIR/config
|
|
|
|
export GIT_WORK_TREE=$(pwd)/repo.git/work
|
|
|
|
test_rev_parse 'outside' false false false
|
|
|
|
cd repo.git || exit 1
|
|
|
|
test_rev_parse 'in repo.git' false true false
|
|
|
|
cd objects || exit 1
|
|
|
|
test_rev_parse 'in repo.git/objects' false true false
|
|
|
|
cd ../work || exit 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>
18 years ago
|
|
|
test_rev_parse 'in repo.git/work' false true true ''
|
|
|
|
cd sub/dir || exit 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>
18 years ago
|
|
|
test_rev_parse 'in repo.git/sub/dir' false true true sub/dir/
|
|
|
|
cd ../../../.. || exit 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>
18 years ago
|
|
|
test_expect_success 'repo finds its work tree' '
|
|
|
|
(cd repo.git &&
|
|
|
|
: > work/sub/dir/untracked &&
|
|
|
|
test sub/dir/untracked = "$(git ls-files --others)")
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'repo finds its work tree from work tree, too' '
|
|
|
|
(cd repo.git/work/sub/dir &&
|
|
|
|
: > tracked &&
|
|
|
|
git --git-dir=../../.. add tracked &&
|
|
|
|
cd ../../.. &&
|
|
|
|
test sub/dir/tracked = "$(git ls-files)")
|
|
|
|
'
|
|
|
|
|
|
|
|
test_done
|