2007-06-06 09:01:21 +02:00
|
|
|
#!/bin/sh
|
|
|
|
|
|
|
|
|
|
test_description='test git rev-parse'
|
|
|
|
|
. ./test-lib.sh
|
|
|
|
|
|
rev-parse: add '--absolute-git-dir' option
The output of 'git rev-parse --git-dir' can be either a relative or an
absolute path, depending on whether the current working directory is
at the top of the worktree or the .git directory or not, or how the
path to the repository is specified via the '--git-dir=<path>' option
or the $GIT_DIR environment variable. And if that output is a
relative path, then it is relative to the directory where any 'git
-C <path>' options might have led us.
This doesn't matter at all for regular scripts, because the git
wrapper automatically takes care of changing directories according to
the '-C <path>' options, and the scripts can then simply follow any
path returned by 'git rev-parse --git-dir', even if it's a relative
path.
Our Bash completion script, however, is unique in that it must run
directly in the user's interactive shell environment. This means that
it's not executed through the git wrapper and would have to take care
of any '-C <path> options on its own, and it can't just change
directories as it pleases. Consequently, adding support for taking
any '-C <path>' options on the command line into account during
completion turned out to be considerably more difficult, error prone
and required more subshells and git processes when it had to cope with
a relative path to the .git directory.
Help this rather special use case and teach 'git rev-parse' a new
'--absolute-git-dir' option which always outputs a canonicalized
absolute path to the .git directory, regardless of whether the path is
discovered automatically or is specified via $GIT_DIR or 'git
--git-dir=<path>'.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 03:48:23 +01:00
|
|
|
# usage: [options] label is-bare is-inside-git is-inside-work prefix git-dir absolute-git-dir
|
2016-05-18 22:15:42 +02:00
|
|
|
test_rev_parse () {
|
2016-05-18 22:15:43 +02:00
|
|
|
d=
|
2016-05-18 22:15:44 +02:00
|
|
|
bare=
|
2016-05-18 22:15:45 +02:00
|
|
|
gitdir=
|
2016-05-18 22:15:43 +02:00
|
|
|
while :
|
|
|
|
|
do
|
|
|
|
|
case "$1" in
|
|
|
|
|
-C) d="$2"; shift; shift ;;
|
2016-05-18 22:15:44 +02:00
|
|
|
-b) case "$2" in
|
|
|
|
|
[tfu]*) bare="$2"; shift; shift ;;
|
|
|
|
|
*) error "test_rev_parse: bogus core.bare value '$2'" ;;
|
|
|
|
|
esac ;;
|
2016-05-18 22:15:45 +02:00
|
|
|
-g) gitdir="$2"; shift; shift ;;
|
2016-05-18 22:15:43 +02:00
|
|
|
-*) error "test_rev_parse: unrecognized option '$1'" ;;
|
|
|
|
|
*) break ;;
|
|
|
|
|
esac
|
|
|
|
|
done
|
|
|
|
|
|
2007-06-06 09:01:21 +02:00
|
|
|
name=$1
|
|
|
|
|
shift
|
|
|
|
|
|
2016-05-18 22:15:42 +02:00
|
|
|
for o in --is-bare-repository \
|
|
|
|
|
--is-inside-git-dir \
|
|
|
|
|
--is-inside-work-tree \
|
|
|
|
|
--show-prefix \
|
rev-parse: add '--absolute-git-dir' option
The output of 'git rev-parse --git-dir' can be either a relative or an
absolute path, depending on whether the current working directory is
at the top of the worktree or the .git directory or not, or how the
path to the repository is specified via the '--git-dir=<path>' option
or the $GIT_DIR environment variable. And if that output is a
relative path, then it is relative to the directory where any 'git
-C <path>' options might have led us.
This doesn't matter at all for regular scripts, because the git
wrapper automatically takes care of changing directories according to
the '-C <path>' options, and the scripts can then simply follow any
path returned by 'git rev-parse --git-dir', even if it's a relative
path.
Our Bash completion script, however, is unique in that it must run
directly in the user's interactive shell environment. This means that
it's not executed through the git wrapper and would have to take care
of any '-C <path> options on its own, and it can't just change
directories as it pleases. Consequently, adding support for taking
any '-C <path>' options on the command line into account during
completion turned out to be considerably more difficult, error prone
and required more subshells and git processes when it had to cope with
a relative path to the .git directory.
Help this rather special use case and teach 'git rev-parse' a new
'--absolute-git-dir' option which always outputs a canonicalized
absolute path to the .git directory, regardless of whether the path is
discovered automatically or is specified via $GIT_DIR or 'git
--git-dir=<path>'.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 03:48:23 +01:00
|
|
|
--git-dir \
|
|
|
|
|
--absolute-git-dir
|
2016-05-18 22:15:42 +02:00
|
|
|
do
|
|
|
|
|
test $# -eq 0 && break
|
|
|
|
|
expect="$1"
|
|
|
|
|
test_expect_success "$name: $o" '
|
2016-05-18 22:15:45 +02:00
|
|
|
if test -n "$gitdir"
|
|
|
|
|
then
|
|
|
|
|
test_when_finished "unset GIT_DIR" &&
|
|
|
|
|
GIT_DIR="$gitdir" &&
|
|
|
|
|
export GIT_DIR
|
|
|
|
|
fi &&
|
|
|
|
|
|
2016-05-18 22:15:44 +02:00
|
|
|
case "$bare" in
|
|
|
|
|
t*) test_config ${d:+-C} ${d:+"$d"} core.bare true ;;
|
|
|
|
|
f*) test_config ${d:+-C} ${d:+"$d"} core.bare false ;;
|
|
|
|
|
u*) test_unconfig ${d:+-C} ${d:+"$d"} core.bare ;;
|
|
|
|
|
esac &&
|
|
|
|
|
|
2016-05-18 22:15:42 +02:00
|
|
|
echo "$expect" >expect &&
|
2016-05-18 22:15:43 +02:00
|
|
|
git ${d:+-C} ${d:+"$d"} rev-parse $o >actual &&
|
2016-05-18 22:15:42 +02:00
|
|
|
test_cmp expect actual
|
|
|
|
|
'
|
|
|
|
|
shift
|
|
|
|
|
done
|
2007-06-06 09:01:21 +02:00
|
|
|
}
|
|
|
|
|
|
2009-02-14 17:16:28 +01:00
|
|
|
ROOT=$(pwd)
|
2007-08-05 15:12:53 +02:00
|
|
|
|
2016-05-17 21:36:26 +02:00
|
|
|
test_expect_success 'setup' '
|
|
|
|
|
mkdir -p sub/dir work &&
|
|
|
|
|
cp -R .git repo.git
|
|
|
|
|
'
|
|
|
|
|
|
rev-parse: add '--absolute-git-dir' option
The output of 'git rev-parse --git-dir' can be either a relative or an
absolute path, depending on whether the current working directory is
at the top of the worktree or the .git directory or not, or how the
path to the repository is specified via the '--git-dir=<path>' option
or the $GIT_DIR environment variable. And if that output is a
relative path, then it is relative to the directory where any 'git
-C <path>' options might have led us.
This doesn't matter at all for regular scripts, because the git
wrapper automatically takes care of changing directories according to
the '-C <path>' options, and the scripts can then simply follow any
path returned by 'git rev-parse --git-dir', even if it's a relative
path.
Our Bash completion script, however, is unique in that it must run
directly in the user's interactive shell environment. This means that
it's not executed through the git wrapper and would have to take care
of any '-C <path> options on its own, and it can't just change
directories as it pleases. Consequently, adding support for taking
any '-C <path>' options on the command line into account during
completion turned out to be considerably more difficult, error prone
and required more subshells and git processes when it had to cope with
a relative path to the .git directory.
Help this rather special use case and teach 'git rev-parse' a new
'--absolute-git-dir' option which always outputs a canonicalized
absolute path to the .git directory, regardless of whether the path is
discovered automatically or is specified via $GIT_DIR or 'git
--git-dir=<path>'.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 03:48:23 +01:00
|
|
|
test_rev_parse toplevel false false true '' .git "$ROOT/.git"
|
2007-06-06 09:01:21 +02:00
|
|
|
|
rev-parse: add '--absolute-git-dir' option
The output of 'git rev-parse --git-dir' can be either a relative or an
absolute path, depending on whether the current working directory is
at the top of the worktree or the .git directory or not, or how the
path to the repository is specified via the '--git-dir=<path>' option
or the $GIT_DIR environment variable. And if that output is a
relative path, then it is relative to the directory where any 'git
-C <path>' options might have led us.
This doesn't matter at all for regular scripts, because the git
wrapper automatically takes care of changing directories according to
the '-C <path>' options, and the scripts can then simply follow any
path returned by 'git rev-parse --git-dir', even if it's a relative
path.
Our Bash completion script, however, is unique in that it must run
directly in the user's interactive shell environment. This means that
it's not executed through the git wrapper and would have to take care
of any '-C <path> options on its own, and it can't just change
directories as it pleases. Consequently, adding support for taking
any '-C <path>' options on the command line into account during
completion turned out to be considerably more difficult, error prone
and required more subshells and git processes when it had to cope with
a relative path to the .git directory.
Help this rather special use case and teach 'git rev-parse' a new
'--absolute-git-dir' option which always outputs a canonicalized
absolute path to the .git directory, regardless of whether the path is
discovered automatically or is specified via $GIT_DIR or 'git
--git-dir=<path>'.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 03:48:23 +01:00
|
|
|
test_rev_parse -C .git .git/ false true false '' . "$ROOT/.git"
|
|
|
|
|
test_rev_parse -C .git/objects .git/objects/ false true false '' "$ROOT/.git" "$ROOT/.git"
|
2007-06-06 09:01:21 +02:00
|
|
|
|
rev-parse: add '--absolute-git-dir' option
The output of 'git rev-parse --git-dir' can be either a relative or an
absolute path, depending on whether the current working directory is
at the top of the worktree or the .git directory or not, or how the
path to the repository is specified via the '--git-dir=<path>' option
or the $GIT_DIR environment variable. And if that output is a
relative path, then it is relative to the directory where any 'git
-C <path>' options might have led us.
This doesn't matter at all for regular scripts, because the git
wrapper automatically takes care of changing directories according to
the '-C <path>' options, and the scripts can then simply follow any
path returned by 'git rev-parse --git-dir', even if it's a relative
path.
Our Bash completion script, however, is unique in that it must run
directly in the user's interactive shell environment. This means that
it's not executed through the git wrapper and would have to take care
of any '-C <path> options on its own, and it can't just change
directories as it pleases. Consequently, adding support for taking
any '-C <path>' options on the command line into account during
completion turned out to be considerably more difficult, error prone
and required more subshells and git processes when it had to cope with
a relative path to the .git directory.
Help this rather special use case and teach 'git rev-parse' a new
'--absolute-git-dir' option which always outputs a canonicalized
absolute path to the .git directory, regardless of whether the path is
discovered automatically or is specified via $GIT_DIR or 'git
--git-dir=<path>'.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 03:48:23 +01:00
|
|
|
test_rev_parse -C sub/dir subdirectory false false true sub/dir/ "$ROOT/.git" "$ROOT/.git"
|
2007-06-06 09:01:21 +02:00
|
|
|
|
2016-05-18 22:15:44 +02:00
|
|
|
test_rev_parse -b t 'core.bare = true' true false false
|
2007-06-06 09:01:21 +02:00
|
|
|
|
2016-05-18 22:15:44 +02:00
|
|
|
test_rev_parse -b u 'core.bare undefined' false false true
|
2007-06-06 09:01:21 +02:00
|
|
|
|
|
|
|
|
|
rev-parse: add '--absolute-git-dir' option
The output of 'git rev-parse --git-dir' can be either a relative or an
absolute path, depending on whether the current working directory is
at the top of the worktree or the .git directory or not, or how the
path to the repository is specified via the '--git-dir=<path>' option
or the $GIT_DIR environment variable. And if that output is a
relative path, then it is relative to the directory where any 'git
-C <path>' options might have led us.
This doesn't matter at all for regular scripts, because the git
wrapper automatically takes care of changing directories according to
the '-C <path>' options, and the scripts can then simply follow any
path returned by 'git rev-parse --git-dir', even if it's a relative
path.
Our Bash completion script, however, is unique in that it must run
directly in the user's interactive shell environment. This means that
it's not executed through the git wrapper and would have to take care
of any '-C <path> options on its own, and it can't just change
directories as it pleases. Consequently, adding support for taking
any '-C <path>' options on the command line into account during
completion turned out to be considerably more difficult, error prone
and required more subshells and git processes when it had to cope with
a relative path to the .git directory.
Help this rather special use case and teach 'git rev-parse' a new
'--absolute-git-dir' option which always outputs a canonicalized
absolute path to the .git directory, regardless of whether the path is
discovered automatically or is specified via $GIT_DIR or 'git
--git-dir=<path>'.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 03:48:23 +01:00
|
|
|
test_rev_parse -C work -g ../.git -b f 'GIT_DIR=../.git, core.bare = false' false false true '' "../.git" "$ROOT/.git"
|
2007-06-06 09:01:21 +02:00
|
|
|
|
2016-05-18 22:15:45 +02:00
|
|
|
test_rev_parse -C work -g ../.git -b t 'GIT_DIR=../.git, core.bare = true' true false false ''
|
2007-06-06 09:01:21 +02:00
|
|
|
|
2016-05-18 22:15:45 +02:00
|
|
|
test_rev_parse -C work -g ../.git -b u 'GIT_DIR=../.git, core.bare undefined' false false true ''
|
2007-06-06 09:01:21 +02:00
|
|
|
|
|
|
|
|
|
rev-parse: add '--absolute-git-dir' option
The output of 'git rev-parse --git-dir' can be either a relative or an
absolute path, depending on whether the current working directory is
at the top of the worktree or the .git directory or not, or how the
path to the repository is specified via the '--git-dir=<path>' option
or the $GIT_DIR environment variable. And if that output is a
relative path, then it is relative to the directory where any 'git
-C <path>' options might have led us.
This doesn't matter at all for regular scripts, because the git
wrapper automatically takes care of changing directories according to
the '-C <path>' options, and the scripts can then simply follow any
path returned by 'git rev-parse --git-dir', even if it's a relative
path.
Our Bash completion script, however, is unique in that it must run
directly in the user's interactive shell environment. This means that
it's not executed through the git wrapper and would have to take care
of any '-C <path> options on its own, and it can't just change
directories as it pleases. Consequently, adding support for taking
any '-C <path>' options on the command line into account during
completion turned out to be considerably more difficult, error prone
and required more subshells and git processes when it had to cope with
a relative path to the .git directory.
Help this rather special use case and teach 'git rev-parse' a new
'--absolute-git-dir' option which always outputs a canonicalized
absolute path to the .git directory, regardless of whether the path is
discovered automatically or is specified via $GIT_DIR or 'git
--git-dir=<path>'.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 03:48:23 +01:00
|
|
|
test_rev_parse -C work -g ../repo.git -b f 'GIT_DIR=../repo.git, core.bare = false' false false true '' "../repo.git" "$ROOT/repo.git"
|
2007-06-06 09:01:21 +02:00
|
|
|
|
2016-05-18 22:15:45 +02:00
|
|
|
test_rev_parse -C work -g ../repo.git -b t 'GIT_DIR=../repo.git, core.bare = true' true false false ''
|
2007-06-06 09:01:21 +02:00
|
|
|
|
2016-05-18 22:15:45 +02:00
|
|
|
test_rev_parse -C work -g ../repo.git -b u 'GIT_DIR=../repo.git, core.bare undefined' false false true ''
|
2007-06-06 09:01:21 +02:00
|
|
|
|
2017-02-17 17:59:02 +01:00
|
|
|
test_expect_success 'git-common-dir from worktree root' '
|
|
|
|
|
echo .git >expect &&
|
|
|
|
|
git rev-parse --git-common-dir >actual &&
|
|
|
|
|
test_cmp expect actual
|
|
|
|
|
'
|
|
|
|
|
|
rev-parse: fix several options when running in a subdirectory
In addition to making git_path() aware of certain file names that need
to be handled differently e.g. when running in worktrees, the commit
557bd833bb (git_path(): be aware of file relocation in $GIT_DIR,
2014-11-30) also snuck in a new option for `git rev-parse`:
`--git-path`.
On the face of it, there is no obvious bug in that commit's diff: it
faithfully calls git_path() on the argument and prints it out, i.e. `git
rev-parse --git-path <filename>` has the same precise behavior as
calling `git_path("<filename>")` in C.
The problem lies deeper, much deeper. In hindsight (which is always
unfair), implementing the .git/ directory discovery in
`setup_git_directory()` by changing the working directory may have
allowed us to avoid passing around a struct that contains information
about the current repository, but it bought us many, many problems.
In this case, when being called in a subdirectory, `git rev-parse`
changes the working directory to the top-level directory before calling
`git_path()`. In the new working directory, the result is correct. But
in the working directory of the calling script, it is incorrect.
Example: when calling `git rev-parse --git-path HEAD` in, say, the
Documentation/ subdirectory of Git's own source code, the string
`.git/HEAD` is printed.
Side note: that bug is hidden when running in a subdirectory of a
worktree that was added by the `git worktree` command: in that case, the
(correct) absolute path of the `HEAD` file is printed.
In the interest of time, this patch does not go the "correct" route to
introduce a struct with repository information (and removing global
state in the process), instead this patch chooses to detect when the
command was called in a subdirectory and forces the result to be an
absolute path.
While at it, we are also fixing the output of --git-common-dir and
--shared-index-path.
Lastly, please note that we reuse the same strbuf for all of the
relative_path() calls; this avoids frequent allocation (and duplicated
code), and it does not risk memory leaks, for two reasons: 1) the
cmd_rev_parse() function does not return anywhere between the use of
the new strbuf instance and its final release, and 2) git-rev-parse is
one of these "one-shot" programs in Git, i.e. it exits after running
for a very short time, meaning that all allocated memory is released
with the exit() call anyway.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-17 17:59:06 +01:00
|
|
|
test_expect_success 'git-common-dir inside sub-dir' '
|
2017-02-17 17:59:02 +01:00
|
|
|
mkdir -p path/to/child &&
|
|
|
|
|
test_when_finished "rm -rf path" &&
|
|
|
|
|
echo "$(git -C path/to/child rev-parse --show-cdup).git" >expect &&
|
|
|
|
|
git -C path/to/child rev-parse --git-common-dir >actual &&
|
|
|
|
|
test_cmp expect actual
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'git-path from worktree root' '
|
|
|
|
|
echo .git/objects >expect &&
|
|
|
|
|
git rev-parse --git-path objects >actual &&
|
|
|
|
|
test_cmp expect actual
|
|
|
|
|
'
|
|
|
|
|
|
rev-parse: fix several options when running in a subdirectory
In addition to making git_path() aware of certain file names that need
to be handled differently e.g. when running in worktrees, the commit
557bd833bb (git_path(): be aware of file relocation in $GIT_DIR,
2014-11-30) also snuck in a new option for `git rev-parse`:
`--git-path`.
On the face of it, there is no obvious bug in that commit's diff: it
faithfully calls git_path() on the argument and prints it out, i.e. `git
rev-parse --git-path <filename>` has the same precise behavior as
calling `git_path("<filename>")` in C.
The problem lies deeper, much deeper. In hindsight (which is always
unfair), implementing the .git/ directory discovery in
`setup_git_directory()` by changing the working directory may have
allowed us to avoid passing around a struct that contains information
about the current repository, but it bought us many, many problems.
In this case, when being called in a subdirectory, `git rev-parse`
changes the working directory to the top-level directory before calling
`git_path()`. In the new working directory, the result is correct. But
in the working directory of the calling script, it is incorrect.
Example: when calling `git rev-parse --git-path HEAD` in, say, the
Documentation/ subdirectory of Git's own source code, the string
`.git/HEAD` is printed.
Side note: that bug is hidden when running in a subdirectory of a
worktree that was added by the `git worktree` command: in that case, the
(correct) absolute path of the `HEAD` file is printed.
In the interest of time, this patch does not go the "correct" route to
introduce a struct with repository information (and removing global
state in the process), instead this patch chooses to detect when the
command was called in a subdirectory and forces the result to be an
absolute path.
While at it, we are also fixing the output of --git-common-dir and
--shared-index-path.
Lastly, please note that we reuse the same strbuf for all of the
relative_path() calls; this avoids frequent allocation (and duplicated
code), and it does not risk memory leaks, for two reasons: 1) the
cmd_rev_parse() function does not return anywhere between the use of
the new strbuf instance and its final release, and 2) git-rev-parse is
one of these "one-shot" programs in Git, i.e. it exits after running
for a very short time, meaning that all allocated memory is released
with the exit() call anyway.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-17 17:59:06 +01:00
|
|
|
test_expect_success 'git-path inside sub-dir' '
|
2017-02-17 17:59:02 +01:00
|
|
|
mkdir -p path/to/child &&
|
|
|
|
|
test_when_finished "rm -rf path" &&
|
|
|
|
|
echo "$(git -C path/to/child rev-parse --show-cdup).git/objects" >expect &&
|
|
|
|
|
git -C path/to/child rev-parse --git-path objects >actual &&
|
|
|
|
|
test_cmp expect actual
|
|
|
|
|
'
|
|
|
|
|
|
2017-09-18 19:04:29 +02:00
|
|
|
test_expect_success 'rev-parse --is-shallow-repository in shallow repo' '
|
|
|
|
|
test_commit test_commit &&
|
|
|
|
|
echo true >expect &&
|
|
|
|
|
git clone --depth 1 --no-local . shallow &&
|
|
|
|
|
test_when_finished "rm -rf shallow" &&
|
|
|
|
|
git -C shallow rev-parse --is-shallow-repository >actual &&
|
|
|
|
|
test_cmp expect actual
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'rev-parse --is-shallow-repository in non-shallow repo' '
|
|
|
|
|
echo false >expect &&
|
|
|
|
|
git rev-parse --is-shallow-repository >actual &&
|
|
|
|
|
test_cmp expect actual
|
|
|
|
|
'
|
|
|
|
|
|
2017-03-09 00:07:42 +01:00
|
|
|
test_expect_success 'showing the superproject correctly' '
|
|
|
|
|
git rev-parse --show-superproject-working-tree >out &&
|
|
|
|
|
test_must_be_empty out &&
|
|
|
|
|
|
|
|
|
|
test_create_repo super &&
|
|
|
|
|
test_commit -C super test_commit &&
|
|
|
|
|
test_create_repo sub &&
|
|
|
|
|
test_commit -C sub test_commit &&
|
|
|
|
|
git -C super submodule add ../sub dir/sub &&
|
|
|
|
|
echo $(pwd)/super >expect &&
|
|
|
|
|
git -C super/dir/sub rev-parse --show-superproject-working-tree >out &&
|
|
|
|
|
test_cmp expect out
|
|
|
|
|
'
|
|
|
|
|
|
2007-06-06 09:01:21 +02:00
|
|
|
test_done
|