2007-08-27 09:58:06 +02:00
|
|
|
#!/bin/sh
|
|
|
|
|
|
|
|
|
|
test_description='git init'
|
|
|
|
|
|
|
|
|
|
. ./test-lib.sh
|
|
|
|
|
|
|
|
|
|
check_config () {
|
|
|
|
|
if test -d "$1" && test -f "$1/config" && test -d "$1/refs"
|
|
|
|
|
then
|
|
|
|
|
: happy
|
|
|
|
|
else
|
|
|
|
|
echo "expected a directory $1, a file $1/config and $1/refs"
|
|
|
|
|
return 1
|
|
|
|
|
fi
|
2014-11-18 14:50:24 +01:00
|
|
|
|
|
|
|
|
if test_have_prereq POSIXPERM && test -x "$1/config"
|
|
|
|
|
then
|
|
|
|
|
echo "$1/config is executable?"
|
|
|
|
|
return 1
|
|
|
|
|
fi
|
|
|
|
|
|
2014-03-21 00:15:24 +01:00
|
|
|
bare=$(cd "$1" && git config --bool core.bare)
|
|
|
|
|
worktree=$(cd "$1" && git config core.worktree) ||
|
2007-08-27 09:58:06 +02:00
|
|
|
worktree=unset
|
|
|
|
|
|
|
|
|
|
test "$bare" = "$2" && test "$worktree" = "$3" || {
|
|
|
|
|
echo "expected bare=$2 worktree=$3"
|
|
|
|
|
echo " got bare=$bare worktree=$worktree"
|
|
|
|
|
return 1
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
test_expect_success 'plain' '
|
2014-03-21 00:23:06 +01:00
|
|
|
git init plain &&
|
2007-08-27 09:58:06 +02:00
|
|
|
check_config plain/.git false unset
|
|
|
|
|
'
|
|
|
|
|
|
2010-11-26 16:32:41 +01:00
|
|
|
test_expect_success 'plain nested in bare' '
|
|
|
|
|
(
|
|
|
|
|
git init --bare bare-ancestor.git &&
|
|
|
|
|
cd bare-ancestor.git &&
|
|
|
|
|
mkdir plain-nested &&
|
|
|
|
|
cd plain-nested &&
|
|
|
|
|
git init
|
|
|
|
|
) &&
|
|
|
|
|
check_config bare-ancestor.git/plain-nested/.git false unset
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'plain through aliased command, outside any git repo' '
|
|
|
|
|
(
|
|
|
|
|
HOME=$(pwd)/alias-config &&
|
|
|
|
|
export HOME &&
|
|
|
|
|
mkdir alias-config &&
|
|
|
|
|
echo "[alias] aliasedinit = init" >alias-config/.gitconfig &&
|
|
|
|
|
|
|
|
|
|
GIT_CEILING_DIRECTORIES=$(pwd) &&
|
|
|
|
|
export GIT_CEILING_DIRECTORIES &&
|
|
|
|
|
|
|
|
|
|
mkdir plain-aliased &&
|
|
|
|
|
cd plain-aliased &&
|
|
|
|
|
git aliasedinit
|
|
|
|
|
) &&
|
|
|
|
|
check_config plain-aliased/.git false unset
|
|
|
|
|
'
|
|
|
|
|
|
2014-06-08 11:37:10 +02:00
|
|
|
test_expect_success 'plain nested through aliased command' '
|
2010-11-26 16:32:41 +01:00
|
|
|
(
|
|
|
|
|
git init plain-ancestor-aliased &&
|
|
|
|
|
cd plain-ancestor-aliased &&
|
|
|
|
|
echo "[alias] aliasedinit = init" >>.git/config &&
|
|
|
|
|
mkdir plain-nested &&
|
|
|
|
|
cd plain-nested &&
|
|
|
|
|
git aliasedinit
|
|
|
|
|
) &&
|
|
|
|
|
check_config plain-ancestor-aliased/plain-nested/.git false unset
|
|
|
|
|
'
|
|
|
|
|
|
2014-06-08 11:37:10 +02:00
|
|
|
test_expect_success 'plain nested in bare through aliased command' '
|
2010-11-26 16:32:41 +01:00
|
|
|
(
|
|
|
|
|
git init --bare bare-ancestor-aliased.git &&
|
|
|
|
|
cd bare-ancestor-aliased.git &&
|
|
|
|
|
echo "[alias] aliasedinit = init" >>config &&
|
|
|
|
|
mkdir plain-nested &&
|
|
|
|
|
cd plain-nested &&
|
|
|
|
|
git aliasedinit
|
|
|
|
|
) &&
|
|
|
|
|
check_config bare-ancestor-aliased.git/plain-nested/.git false unset
|
2007-08-27 09:58:06 +02:00
|
|
|
'
|
|
|
|
|
|
2015-12-20 08:50:19 +01:00
|
|
|
test_expect_success 'No extra GIT_* on alias scripts' '
|
2016-03-03 07:55:17 +01:00
|
|
|
write_script script <<-\EOF &&
|
|
|
|
|
env |
|
|
|
|
|
sed -n \
|
|
|
|
|
-e "/^GIT_PREFIX=/d" \
|
|
|
|
|
-e "/^GIT_TEXTDOMAINDIR=/d" \
|
2019-02-22 23:25:01 +01:00
|
|
|
-e "/^GIT_TR2_PARENT/d" \
|
2016-03-03 07:55:17 +01:00
|
|
|
-e "/^GIT_/s/=.*//p" |
|
|
|
|
|
sort
|
2015-12-20 08:50:19 +01:00
|
|
|
EOF
|
2016-03-03 07:55:17 +01:00
|
|
|
./script >expected &&
|
2015-12-20 08:50:19 +01:00
|
|
|
git config alias.script \!./script &&
|
2016-03-03 07:55:17 +01:00
|
|
|
( mkdir sub && cd sub && git script >../actual ) &&
|
2015-12-20 08:50:19 +01:00
|
|
|
test_cmp expected actual
|
|
|
|
|
'
|
|
|
|
|
|
2007-08-27 09:58:06 +02:00
|
|
|
test_expect_success 'plain with GIT_WORK_TREE' '
|
2014-03-21 00:19:50 +01:00
|
|
|
mkdir plain-wt &&
|
|
|
|
|
test_must_fail env GIT_WORK_TREE="$(pwd)/plain-wt" git init plain-wt
|
2007-08-27 09:58:06 +02:00
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'plain bare' '
|
2014-03-21 00:23:06 +01:00
|
|
|
git --bare init plain-bare-1 &&
|
2007-08-27 09:58:06 +02:00
|
|
|
check_config plain-bare-1 true unset
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'plain bare with GIT_WORK_TREE' '
|
2014-03-21 00:19:50 +01:00
|
|
|
mkdir plain-bare-2 &&
|
|
|
|
|
test_must_fail \
|
|
|
|
|
env GIT_WORK_TREE="$(pwd)/plain-bare-2" \
|
|
|
|
|
git --bare init plain-bare-2
|
2007-08-27 09:58:06 +02:00
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'GIT_DIR bare' '
|
2014-03-21 00:21:25 +01:00
|
|
|
mkdir git-dir-bare.git &&
|
|
|
|
|
GIT_DIR=git-dir-bare.git git init &&
|
2007-08-27 09:58:06 +02:00
|
|
|
check_config git-dir-bare.git true unset
|
|
|
|
|
'
|
|
|
|
|
|
2008-05-28 20:53:57 +02:00
|
|
|
test_expect_success 'init --bare' '
|
2014-03-21 00:23:06 +01:00
|
|
|
git init --bare init-bare.git &&
|
2008-07-11 02:12:03 +02:00
|
|
|
check_config init-bare.git true unset
|
2008-05-28 20:53:57 +02:00
|
|
|
'
|
|
|
|
|
|
2007-08-27 09:58:06 +02:00
|
|
|
test_expect_success 'GIT_DIR non-bare' '
|
|
|
|
|
|
|
|
|
|
(
|
|
|
|
|
mkdir non-bare &&
|
|
|
|
|
cd non-bare &&
|
|
|
|
|
GIT_DIR=.git git init
|
|
|
|
|
) &&
|
|
|
|
|
check_config non-bare/.git false unset
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'GIT_DIR & GIT_WORK_TREE (1)' '
|
|
|
|
|
|
|
|
|
|
(
|
|
|
|
|
mkdir git-dir-wt-1.git &&
|
|
|
|
|
GIT_WORK_TREE=$(pwd) GIT_DIR=git-dir-wt-1.git git init
|
|
|
|
|
) &&
|
|
|
|
|
check_config git-dir-wt-1.git false "$(pwd)"
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'GIT_DIR & GIT_WORK_TREE (2)' '
|
2014-03-21 00:19:50 +01:00
|
|
|
mkdir git-dir-wt-2.git &&
|
|
|
|
|
test_must_fail env \
|
|
|
|
|
GIT_WORK_TREE="$(pwd)" \
|
|
|
|
|
GIT_DIR=git-dir-wt-2.git \
|
|
|
|
|
git --bare init
|
2007-08-27 09:58:06 +02:00
|
|
|
'
|
|
|
|
|
|
2011-04-13 00:57:08 +02:00
|
|
|
test_expect_success 'reinit' '
|
2008-03-24 16:14:52 +01:00
|
|
|
|
|
|
|
|
(
|
|
|
|
|
mkdir again &&
|
|
|
|
|
cd again &&
|
|
|
|
|
git init >out1 2>err1 &&
|
|
|
|
|
git init >out2 2>err2
|
|
|
|
|
) &&
|
2011-04-13 00:57:08 +02:00
|
|
|
test_i18ngrep "Initialized empty" again/out1 &&
|
|
|
|
|
test_i18ngrep "Reinitialized existing" again/out2 &&
|
tests: use 'test_must_be_empty' instead of 'test_cmp <empty> <out>'
Using 'test_must_be_empty' is shorter and more idiomatic than
>empty &&
test_cmp empty out
as it saves the creation of an empty file. Furthermore, sometimes the
expected empty file doesn't have such a descriptive name like 'empty',
and its creation is far away from the place where it's finally used
for comparison (e.g. in 't7600-merge.sh', where two expected empty
files are created in the 'setup' test, but are used only about 500
lines later).
These cases were found by instrumenting 'test_cmp' to error out the
test script when it's used to compare empty files, and then converted
manually.
Note that even after this patch there still remain a lot of cases
where we use 'test_cmp' to check empty files:
- Sometimes the expected output is not hard-coded in the test, but
'test_cmp' is used to ensure that two similar git commands produce
the same output, and that output happens to be empty, e.g. the
test 'submodule update --merge - ignores --merge for new
submodules' in 't7406-submodule-update.sh'.
- Repetitive common tasks, including preparing the expected results
and running 'test_cmp', are often extracted into a helper
function, and some of this helper's callsites expect no output.
- For the same reason as above, the whole 'test_expect_success'
block is within a helper function, e.g. in 't3070-wildmatch.sh'.
- Or 'test_cmp' is invoked in a loop, e.g. the test 'cvs update
(-p)' in 't9400-git-cvsserver-server.sh'.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-19 23:57:25 +02:00
|
|
|
test_must_be_empty again/err1 &&
|
|
|
|
|
test_must_be_empty again/err2
|
2008-03-24 16:14:52 +01:00
|
|
|
'
|
|
|
|
|
|
2008-07-28 08:02:04 +02:00
|
|
|
test_expect_success 'init with --template' '
|
|
|
|
|
mkdir template-source &&
|
|
|
|
|
echo content >template-source/file &&
|
2014-03-21 00:23:06 +01:00
|
|
|
git init --template=../template-source template-custom &&
|
2008-07-28 08:02:04 +02:00
|
|
|
test_cmp template-source/file template-custom/.git/file
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'init with --template (blank)' '
|
2014-03-21 00:23:06 +01:00
|
|
|
git init template-plain &&
|
2014-03-21 00:17:35 +01:00
|
|
|
test_path_is_file template-plain/.git/info/exclude &&
|
2014-03-21 00:23:06 +01:00
|
|
|
git init --template= template-blank &&
|
2014-03-21 00:17:35 +01:00
|
|
|
test_path_is_missing template-blank/.git/info/exclude
|
2008-07-28 08:02:04 +02:00
|
|
|
'
|
|
|
|
|
|
2010-02-26 05:00:21 +01:00
|
|
|
test_expect_success 'init with init.templatedir set' '
|
|
|
|
|
mkdir templatedir-source &&
|
|
|
|
|
echo Content >templatedir-source/file &&
|
2014-03-21 00:18:12 +01:00
|
|
|
test_config_global init.templatedir "${HOME}/templatedir-source" &&
|
2010-02-26 05:00:21 +01:00
|
|
|
(
|
|
|
|
|
mkdir templatedir-set &&
|
|
|
|
|
cd templatedir-set &&
|
2010-10-03 22:00:14 +02:00
|
|
|
sane_unset GIT_TEMPLATE_DIR &&
|
2010-02-26 05:00:21 +01:00
|
|
|
NO_SET_GIT_TEMPLATE_DIR=t &&
|
|
|
|
|
export NO_SET_GIT_TEMPLATE_DIR &&
|
|
|
|
|
git init
|
|
|
|
|
) &&
|
|
|
|
|
test_cmp templatedir-source/file templatedir-set/.git/file
|
|
|
|
|
'
|
|
|
|
|
|
git init: --bare/--shared overrides system/global config
If core.bare or core.sharedRepository are set in /etc/gitconfig or
~/.gitconfig, then 'git init' will read the values when constructing a
new config file; reading them, however, will override the values
specified on the command line. In the case of --bare, this ends up
causing a segfault, without the repository being properly initialised;
in the case of --shared, the permissions are set according to the
existing config settings, not what was specified on the command line.
This fix saves any specified values for --bare and --shared prior to
reading existing config settings, and restores them after reading but
before writing the new config file. core.bare is ignored in all
situations, while core.sharedRepository will only be used if --shared
is not specified to git init.
Also includes testcases which use a specified global config file
override, demonstrating the former failure scenario.
Signed-off-by: Deskin Miller <deskinm@umich.edu>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2008-10-07 07:37:48 +02:00
|
|
|
test_expect_success 'init --bare/--shared overrides system/global config' '
|
2014-03-21 00:18:12 +01:00
|
|
|
test_config_global core.bare false &&
|
|
|
|
|
test_config_global core.sharedRepository 0640 &&
|
2014-03-21 00:23:06 +01:00
|
|
|
git init --bare --shared=0666 init-bare-shared-override &&
|
git init: --bare/--shared overrides system/global config
If core.bare or core.sharedRepository are set in /etc/gitconfig or
~/.gitconfig, then 'git init' will read the values when constructing a
new config file; reading them, however, will override the values
specified on the command line. In the case of --bare, this ends up
causing a segfault, without the repository being properly initialised;
in the case of --shared, the permissions are set according to the
existing config settings, not what was specified on the command line.
This fix saves any specified values for --bare and --shared prior to
reading existing config settings, and restores them after reading but
before writing the new config file. core.bare is ignored in all
situations, while core.sharedRepository will only be used if --shared
is not specified to git init.
Also includes testcases which use a specified global config file
override, demonstrating the former failure scenario.
Signed-off-by: Deskin Miller <deskinm@umich.edu>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2008-10-07 07:37:48 +02:00
|
|
|
check_config init-bare-shared-override true unset &&
|
|
|
|
|
test x0666 = \
|
2014-04-28 14:57:24 +02:00
|
|
|
x$(git config -f init-bare-shared-override/config core.sharedRepository)
|
git init: --bare/--shared overrides system/global config
If core.bare or core.sharedRepository are set in /etc/gitconfig or
~/.gitconfig, then 'git init' will read the values when constructing a
new config file; reading them, however, will override the values
specified on the command line. In the case of --bare, this ends up
causing a segfault, without the repository being properly initialised;
in the case of --shared, the permissions are set according to the
existing config settings, not what was specified on the command line.
This fix saves any specified values for --bare and --shared prior to
reading existing config settings, and restores them after reading but
before writing the new config file. core.bare is ignored in all
situations, while core.sharedRepository will only be used if --shared
is not specified to git init.
Also includes testcases which use a specified global config file
override, demonstrating the former failure scenario.
Signed-off-by: Deskin Miller <deskinm@umich.edu>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2008-10-07 07:37:48 +02:00
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'init honors global core.sharedRepository' '
|
2014-03-21 00:18:12 +01:00
|
|
|
test_config_global core.sharedRepository 0666 &&
|
2014-03-21 00:23:06 +01:00
|
|
|
git init shared-honor-global &&
|
git init: --bare/--shared overrides system/global config
If core.bare or core.sharedRepository are set in /etc/gitconfig or
~/.gitconfig, then 'git init' will read the values when constructing a
new config file; reading them, however, will override the values
specified on the command line. In the case of --bare, this ends up
causing a segfault, without the repository being properly initialised;
in the case of --shared, the permissions are set according to the
existing config settings, not what was specified on the command line.
This fix saves any specified values for --bare and --shared prior to
reading existing config settings, and restores them after reading but
before writing the new config file. core.bare is ignored in all
situations, while core.sharedRepository will only be used if --shared
is not specified to git init.
Also includes testcases which use a specified global config file
override, demonstrating the former failure scenario.
Signed-off-by: Deskin Miller <deskinm@umich.edu>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2008-10-07 07:37:48 +02:00
|
|
|
test x0666 = \
|
2014-04-28 14:57:24 +02:00
|
|
|
x$(git config -f shared-honor-global/.git/config core.sharedRepository)
|
git init: --bare/--shared overrides system/global config
If core.bare or core.sharedRepository are set in /etc/gitconfig or
~/.gitconfig, then 'git init' will read the values when constructing a
new config file; reading them, however, will override the values
specified on the command line. In the case of --bare, this ends up
causing a segfault, without the repository being properly initialised;
in the case of --shared, the permissions are set according to the
existing config settings, not what was specified on the command line.
This fix saves any specified values for --bare and --shared prior to
reading existing config settings, and restores them after reading but
before writing the new config file. core.bare is ignored in all
situations, while core.sharedRepository will only be used if --shared
is not specified to git init.
Also includes testcases which use a specified global config file
override, demonstrating the former failure scenario.
Signed-off-by: Deskin Miller <deskinm@umich.edu>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2008-10-07 07:37:48 +02:00
|
|
|
'
|
|
|
|
|
|
2015-10-05 05:46:04 +02:00
|
|
|
test_expect_success 'init allows insanely long --template' '
|
|
|
|
|
git init --template=$(printf "x%09999dx" 1) test
|
2009-04-18 16:14:02 +02:00
|
|
|
'
|
|
|
|
|
|
2009-07-24 23:59:28 +02:00
|
|
|
test_expect_success 'init creates a new directory' '
|
|
|
|
|
rm -fr newdir &&
|
2014-03-21 00:21:25 +01:00
|
|
|
git init newdir &&
|
|
|
|
|
test_path_is_dir newdir/.git/refs
|
2009-07-24 23:59:28 +02:00
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'init creates a new bare directory' '
|
|
|
|
|
rm -fr newdir &&
|
2014-03-21 00:21:25 +01:00
|
|
|
git init --bare newdir &&
|
|
|
|
|
test_path_is_dir newdir/refs
|
2009-07-24 23:59:28 +02:00
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'init recreates a directory' '
|
|
|
|
|
rm -fr newdir &&
|
2014-03-21 00:21:25 +01:00
|
|
|
mkdir newdir &&
|
|
|
|
|
git init newdir &&
|
|
|
|
|
test_path_is_dir newdir/.git/refs
|
2009-07-24 23:59:28 +02:00
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'init recreates a new bare directory' '
|
|
|
|
|
rm -fr newdir &&
|
2014-03-21 00:21:25 +01:00
|
|
|
mkdir newdir &&
|
|
|
|
|
git init --bare newdir &&
|
|
|
|
|
test_path_is_dir newdir/refs
|
2009-07-24 23:59:28 +02:00
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'init creates a new deep directory' '
|
2009-08-09 18:02:55 +02:00
|
|
|
rm -fr newdir &&
|
|
|
|
|
git init newdir/a/b/c &&
|
2014-03-21 00:17:35 +01:00
|
|
|
test_path_is_dir newdir/a/b/c/.git/refs
|
2009-08-09 18:02:55 +02:00
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success POSIXPERM 'init creates a new deep directory (umask vs. shared)' '
|
2009-07-24 23:59:28 +02:00
|
|
|
rm -fr newdir &&
|
|
|
|
|
(
|
|
|
|
|
# Leading directories should honor umask while
|
|
|
|
|
# the repository itself should follow "shared"
|
2017-01-28 21:25:48 +01:00
|
|
|
mkdir newdir &&
|
|
|
|
|
# Remove a default ACL if possible.
|
|
|
|
|
(setfacl -k newdir 2>/dev/null || true) &&
|
2009-07-24 23:59:28 +02:00
|
|
|
umask 002 &&
|
|
|
|
|
git init --bare --shared=0660 newdir/a/b/c &&
|
2014-03-21 00:17:35 +01:00
|
|
|
test_path_is_dir newdir/a/b/c/refs &&
|
2009-07-24 23:59:28 +02:00
|
|
|
ls -ld newdir/a newdir/a/b > lsab.out &&
|
2009-08-09 17:38:04 +02:00
|
|
|
! grep -v "^drwxrw[sx]r-x" lsab.out &&
|
2009-07-24 23:59:28 +02:00
|
|
|
ls -ld newdir/a/b/c > lsc.out &&
|
|
|
|
|
! grep -v "^drwxrw[sx]---" lsc.out
|
|
|
|
|
)
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'init notices EEXIST (1)' '
|
|
|
|
|
rm -fr newdir &&
|
2014-03-21 00:21:25 +01:00
|
|
|
>newdir &&
|
|
|
|
|
test_must_fail git init newdir &&
|
|
|
|
|
test_path_is_file newdir
|
2009-07-24 23:59:28 +02:00
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'init notices EEXIST (2)' '
|
|
|
|
|
rm -fr newdir &&
|
2014-03-21 00:21:25 +01:00
|
|
|
mkdir newdir &&
|
|
|
|
|
>newdir/a &&
|
|
|
|
|
test_must_fail git init newdir/a/b &&
|
|
|
|
|
test_path_is_file newdir/a
|
2009-07-24 23:59:28 +02:00
|
|
|
'
|
|
|
|
|
|
2010-08-07 00:09:09 +02:00
|
|
|
test_expect_success POSIXPERM,SANITY 'init notices EPERM' '
|
2018-06-15 20:13:39 +02:00
|
|
|
test_when_finished "chmod +w newdir" &&
|
2009-07-24 23:59:28 +02:00
|
|
|
rm -fr newdir &&
|
2014-03-21 00:21:25 +01:00
|
|
|
mkdir newdir &&
|
|
|
|
|
chmod -w newdir &&
|
|
|
|
|
test_must_fail git init newdir/a/b
|
2009-07-24 23:59:28 +02:00
|
|
|
'
|
|
|
|
|
|
handle "git --bare init <dir>" properly
If we know we are creating a bare repository, we use setenv
to set the GIT_DIR directory to the current directory
(either where we already were, or one we created and chdir'd
into with "git init --bare <dir>").
However, with "git --bare init <dir>" (note the --bare as a
git wrapper option), the setup code actually sets GIT_DIR
for us, but it uses the wrong, original cwd when a directory
is given. Because our setenv does not use the overwrite
flag, it is ignored.
We need to set the overwrite flag, but only when we are
given a directory on the command line. That still allows:
GIT_DIR=foo.git git init --bare
to work. The behavior is changed for:
GIT_DIR=foo.git git init --bare bar.git
which used to create the repository in foo.git, but now will
use bar.git. This is more sane, as command line options
should generally override the environment.
Noticed by Oliver Hoffmann.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-05-10 11:42:06 +02:00
|
|
|
test_expect_success 'init creates a new bare directory with global --bare' '
|
|
|
|
|
rm -rf newdir &&
|
|
|
|
|
git --bare init newdir &&
|
2014-03-21 00:17:35 +01:00
|
|
|
test_path_is_dir newdir/refs
|
handle "git --bare init <dir>" properly
If we know we are creating a bare repository, we use setenv
to set the GIT_DIR directory to the current directory
(either where we already were, or one we created and chdir'd
into with "git init --bare <dir>").
However, with "git --bare init <dir>" (note the --bare as a
git wrapper option), the setup code actually sets GIT_DIR
for us, but it uses the wrong, original cwd when a directory
is given. Because our setenv does not use the overwrite
flag, it is ignored.
We need to set the overwrite flag, but only when we are
given a directory on the command line. That still allows:
GIT_DIR=foo.git git init --bare
to work. The behavior is changed for:
GIT_DIR=foo.git git init --bare bar.git
which used to create the repository in foo.git, but now will
use bar.git. This is more sane, as command line options
should generally override the environment.
Noticed by Oliver Hoffmann.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-05-10 11:42:06 +02:00
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'init prefers command line to GIT_DIR' '
|
|
|
|
|
rm -rf newdir &&
|
|
|
|
|
mkdir otherdir &&
|
|
|
|
|
GIT_DIR=otherdir git --bare init newdir &&
|
2014-03-21 00:17:35 +01:00
|
|
|
test_path_is_dir newdir/refs &&
|
|
|
|
|
test_path_is_missing otherdir/refs
|
handle "git --bare init <dir>" properly
If we know we are creating a bare repository, we use setenv
to set the GIT_DIR directory to the current directory
(either where we already were, or one we created and chdir'd
into with "git init --bare <dir>").
However, with "git --bare init <dir>" (note the --bare as a
git wrapper option), the setup code actually sets GIT_DIR
for us, but it uses the wrong, original cwd when a directory
is given. Because our setenv does not use the overwrite
flag, it is ignored.
We need to set the overwrite flag, but only when we are
given a directory on the command line. That still allows:
GIT_DIR=foo.git git init --bare
to work. The behavior is changed for:
GIT_DIR=foo.git git init --bare bar.git
which used to create the repository in foo.git, but now will
use bar.git. This is more sane, as command line options
should generally override the environment.
Noticed by Oliver Hoffmann.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-05-10 11:42:06 +02:00
|
|
|
'
|
|
|
|
|
|
2011-03-19 16:16:56 +01:00
|
|
|
test_expect_success 'init with separate gitdir' '
|
|
|
|
|
rm -rf newdir &&
|
|
|
|
|
git init --separate-git-dir realgitdir newdir &&
|
2014-04-28 14:57:24 +02:00
|
|
|
echo "gitdir: $(pwd)/realgitdir" >expected &&
|
2011-03-19 16:16:56 +01:00
|
|
|
test_cmp expected newdir/.git &&
|
2014-03-21 00:17:35 +01:00
|
|
|
test_path_is_dir realgitdir/refs
|
2011-03-19 16:16:56 +01:00
|
|
|
'
|
|
|
|
|
|
2017-08-07 13:04:18 +02:00
|
|
|
test_lazy_prereq GETCWD_IGNORES_PERMS '
|
|
|
|
|
base=GETCWD_TEST_BASE_DIR &&
|
|
|
|
|
mkdir -p $base/dir &&
|
|
|
|
|
chmod 100 $base ||
|
tests: send "bug in the test script" errors to the script's stderr
Some of the functions in our test library check that they were invoked
properly with conditions like this:
test "$#" = 2 ||
error "bug in the test script: not 2 parameters to test-expect-success"
If this particular condition is triggered, then 'error' will abort the
whole test script with a bold red error message [1] right away.
However, under certain circumstances the test script will be aborted
completely silently, namely if:
- a similar condition in a test helper function like
'test_line_count' is triggered,
- which is invoked from the test script's "main" shell [2],
- and the test script is run manually (i.e. './t1234-foo.sh' as
opposed to 'make t1234-foo.sh' or 'make test') [3]
- and without the '--verbose' option,
because the error message is printed from within 'test_eval_', where
standard output is redirected either to /dev/null or to a log file.
The only indication that something is wrong is that not all tests in
the script are executed and at the end of the test script's output
there is no "# passed all N tests" message, which are subtle and can
easily go unnoticed, as I had to experience myself.
Send these "bug in the test script" error messages directly to the
test scripts standard error and thus to the terminal, so those bugs
will be much harder to overlook. Instead of updating all ~20 such
'error' calls with a redirection, let's add a BUG() function to
'test-lib.sh', wrapping an 'error' call with the proper redirection
and also including the common prefix of those error messages, and
convert all those call sites [4] to use this new BUG() function
instead.
[1] That particular error message from 'test_expect_success' is
printed in color only when running with or without '--verbose';
with '--tee' or '--verbose-log' the error is printed without
color, but it is printed to the terminal nonetheless.
[2] If such a condition is triggered in a subshell of a test, then
'error' won't be able to abort the whole test script, but only the
subshell, which in turn causes the test to fail in the usual way,
indicating loudly and clearly that something is wrong.
[3] Well, 'error' aborts the test script the same way when run
manually or by 'make' or 'prove', but both 'make' and 'prove' pay
attention to the test script's exit status, and even a silently
aborted test script would then trigger those tools' usual
noticable error messages.
[4] Strictly speaking, not all those 'error' calls need that
redirection to send their output to the terminal, see e.g.
'test_expect_success' in the opening example, but I think it's
better to be consistent.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-19 14:13:26 +01:00
|
|
|
BUG "cannot prepare $base"
|
2017-08-07 13:04:18 +02:00
|
|
|
|
|
|
|
|
(cd $base/dir && /bin/pwd -P)
|
|
|
|
|
status=$?
|
|
|
|
|
|
|
|
|
|
chmod 700 $base &&
|
|
|
|
|
rm -rf $base ||
|
tests: send "bug in the test script" errors to the script's stderr
Some of the functions in our test library check that they were invoked
properly with conditions like this:
test "$#" = 2 ||
error "bug in the test script: not 2 parameters to test-expect-success"
If this particular condition is triggered, then 'error' will abort the
whole test script with a bold red error message [1] right away.
However, under certain circumstances the test script will be aborted
completely silently, namely if:
- a similar condition in a test helper function like
'test_line_count' is triggered,
- which is invoked from the test script's "main" shell [2],
- and the test script is run manually (i.e. './t1234-foo.sh' as
opposed to 'make t1234-foo.sh' or 'make test') [3]
- and without the '--verbose' option,
because the error message is printed from within 'test_eval_', where
standard output is redirected either to /dev/null or to a log file.
The only indication that something is wrong is that not all tests in
the script are executed and at the end of the test script's output
there is no "# passed all N tests" message, which are subtle and can
easily go unnoticed, as I had to experience myself.
Send these "bug in the test script" error messages directly to the
test scripts standard error and thus to the terminal, so those bugs
will be much harder to overlook. Instead of updating all ~20 such
'error' calls with a redirection, let's add a BUG() function to
'test-lib.sh', wrapping an 'error' call with the proper redirection
and also including the common prefix of those error messages, and
convert all those call sites [4] to use this new BUG() function
instead.
[1] That particular error message from 'test_expect_success' is
printed in color only when running with or without '--verbose';
with '--tee' or '--verbose-log' the error is printed without
color, but it is printed to the terminal nonetheless.
[2] If such a condition is triggered in a subshell of a test, then
'error' won't be able to abort the whole test script, but only the
subshell, which in turn causes the test to fail in the usual way,
indicating loudly and clearly that something is wrong.
[3] Well, 'error' aborts the test script the same way when run
manually or by 'make' or 'prove', but both 'make' and 'prove' pay
attention to the test script's exit status, and even a silently
aborted test script would then trigger those tools' usual
noticable error messages.
[4] Strictly speaking, not all those 'error' calls need that
redirection to send their output to the terminal, see e.g.
'test_expect_success' in the opening example, but I think it's
better to be consistent.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-19 14:13:26 +01:00
|
|
|
BUG "cannot clean $base"
|
2017-08-07 13:04:18 +02:00
|
|
|
return $status
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
check_long_base_path () {
|
2017-03-26 15:43:50 +02:00
|
|
|
# exceed initial buffer size of strbuf_getcwd()
|
|
|
|
|
component=123456789abcdef &&
|
|
|
|
|
test_when_finished "chmod 0700 $component; rm -rf $component" &&
|
|
|
|
|
p31=$component/$component &&
|
|
|
|
|
p127=$p31/$p31/$p31/$p31 &&
|
|
|
|
|
mkdir -p $p127 &&
|
2017-08-07 13:04:18 +02:00
|
|
|
if test $# = 1
|
|
|
|
|
then
|
|
|
|
|
chmod $1 $component
|
|
|
|
|
fi &&
|
2017-03-26 15:43:50 +02:00
|
|
|
(
|
|
|
|
|
cd $p127 &&
|
|
|
|
|
git init newdir
|
|
|
|
|
)
|
2017-08-07 13:04:18 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
test_expect_success 'init in long base path' '
|
|
|
|
|
check_long_base_path
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success GETCWD_IGNORES_PERMS 'init in long restricted base path' '
|
|
|
|
|
check_long_base_path 0111
|
2017-03-26 15:43:50 +02:00
|
|
|
'
|
|
|
|
|
|
2013-08-31 03:04:14 +02:00
|
|
|
test_expect_success 're-init on .git file' '
|
|
|
|
|
( cd newdir && git init )
|
|
|
|
|
'
|
|
|
|
|
|
2011-03-19 16:16:56 +01:00
|
|
|
test_expect_success 're-init to update git link' '
|
|
|
|
|
(
|
|
|
|
|
cd newdir &&
|
|
|
|
|
git init --separate-git-dir ../surrealgitdir
|
|
|
|
|
) &&
|
2014-04-28 14:57:24 +02:00
|
|
|
echo "gitdir: $(pwd)/surrealgitdir" >expected &&
|
2011-03-19 16:16:56 +01:00
|
|
|
test_cmp expected newdir/.git &&
|
2014-03-21 00:17:35 +01:00
|
|
|
test_path_is_dir surrealgitdir/refs &&
|
|
|
|
|
test_path_is_missing realgitdir/refs
|
2011-03-19 16:16:56 +01:00
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 're-init to move gitdir' '
|
|
|
|
|
rm -rf newdir realgitdir surrealgitdir &&
|
|
|
|
|
git init newdir &&
|
|
|
|
|
(
|
|
|
|
|
cd newdir &&
|
|
|
|
|
git init --separate-git-dir ../realgitdir
|
|
|
|
|
) &&
|
2014-04-28 14:57:24 +02:00
|
|
|
echo "gitdir: $(pwd)/realgitdir" >expected &&
|
2011-03-19 16:16:56 +01:00
|
|
|
test_cmp expected newdir/.git &&
|
2014-03-21 00:17:35 +01:00
|
|
|
test_path_is_dir realgitdir/refs
|
2011-03-19 16:16:56 +01:00
|
|
|
'
|
|
|
|
|
|
2011-04-12 08:30:49 +02:00
|
|
|
test_expect_success SYMLINKS 're-init to move gitdir symlink' '
|
2011-03-19 16:16:56 +01:00
|
|
|
rm -rf newdir realgitdir &&
|
|
|
|
|
git init newdir &&
|
|
|
|
|
(
|
|
|
|
|
cd newdir &&
|
|
|
|
|
mv .git here &&
|
|
|
|
|
ln -s here .git &&
|
2011-05-24 18:40:32 +02:00
|
|
|
git init --separate-git-dir ../realgitdir
|
2011-03-19 16:16:56 +01:00
|
|
|
) &&
|
2014-04-28 14:57:24 +02:00
|
|
|
echo "gitdir: $(pwd)/realgitdir" >expected &&
|
2011-03-19 16:16:56 +01:00
|
|
|
test_cmp expected newdir/.git &&
|
2014-03-21 00:17:15 +01:00
|
|
|
test_cmp expected newdir/here &&
|
2014-03-21 00:17:35 +01:00
|
|
|
test_path_is_dir realgitdir/refs
|
2011-03-19 16:16:56 +01:00
|
|
|
'
|
|
|
|
|
|
mingw: introduce the 'core.hideDotFiles' setting
On Unix (and Linux), files and directories whose names start with a dot
are usually not shown by default. This convention is used by Git: the
.git/ directory should be left alone by regular users, and only accessed
through Git itself.
On Windows, no such convention exists. Instead, there is an explicit flag
to mark files or directories as hidden.
In the early days, Git for Windows did not mark the .git/ directory (or
for that matter, any file or directory whose name starts with a dot)
hidden. This lead to quite a bit of confusion, and even loss of data.
Consequently, Git for Windows introduced the core.hideDotFiles setting,
with three possible values: true, false, and dotGitOnly, defaulting to
marking only the .git/ directory as hidden.
The rationale: users do not need to access .git/ directly, and indeed (as
was demonstrated) should not really see that directory, either. However,
not all dot files should be hidden by default, as e.g. Eclipse does not
show them (and the user would therefore be unable to see, say, a
.gitattributes file).
In over five years since the last attempt to bring this patch into core
Git, a slightly buggy version of this patch has served Git for Windows'
users well: no single report indicated problems with the hidden .git/
directory, and the stream of problems caused by the previously non-hidden
.git/ directory simply stopped. The bugs have been fixed during the
process of getting this patch upstream.
Note that there is a funny quirk we have to pay attention to when
creating hidden files: we use Win32's _wopen() function which
transmogrifies its arguments and hands off to Win32's CreateFile()
function. That latter function errors out with ERROR_ACCESS_DENIED (the
equivalent of EACCES) when the equivalent of the O_CREAT flag was passed
and the file attributes (including the hidden flag) do not match an
existing file's. And _wopen() accepts no parameter that would be
transmogrified into said hidden flag. Therefore, we simply try again
without O_CREAT.
A slightly different method is required for our fopen()/freopen()
function as we cannot even *remove* the implicit O_CREAT flag.
Therefore, we briefly mark existing files as unhidden when opening them
via fopen()/freopen().
The ERROR_ACCESS_DENIED error can also be triggered by opening a file
that is marked as a system file (which is unlikely to be tracked in
Git), and by trying to create a file that has *just* been deleted and is
awaiting the last open handles to be released (which would be handled
better by the "Try again?" logic, a story for a different patch series,
though). In both cases, it does not matter much if we try again without
the O_CREAT flag, read: it does not hurt, either.
For details how ERROR_ACCESS_DENIED can be triggered, see
https://msdn.microsoft.com/en-us/library/windows/desktop/aa363858
Original-patch-by: Erik Faye-Lund <kusmabite@gmail.com>
Initial-Test-By: Pat Thoyts <patthoyts@users.sourceforge.net>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-11 10:43:37 +02:00
|
|
|
# Tests for the hidden file attribute on windows
|
|
|
|
|
is_hidden () {
|
|
|
|
|
# Use the output of `attrib`, ignore the absolute path
|
|
|
|
|
case "$(attrib "$1")" in *H*?:*) return 0;; esac
|
|
|
|
|
return 1
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
test_expect_success MINGW '.git hidden' '
|
|
|
|
|
rm -rf newdir &&
|
|
|
|
|
(
|
2018-07-02 02:23:43 +02:00
|
|
|
sane_unset GIT_DIR GIT_WORK_TREE &&
|
mingw: introduce the 'core.hideDotFiles' setting
On Unix (and Linux), files and directories whose names start with a dot
are usually not shown by default. This convention is used by Git: the
.git/ directory should be left alone by regular users, and only accessed
through Git itself.
On Windows, no such convention exists. Instead, there is an explicit flag
to mark files or directories as hidden.
In the early days, Git for Windows did not mark the .git/ directory (or
for that matter, any file or directory whose name starts with a dot)
hidden. This lead to quite a bit of confusion, and even loss of data.
Consequently, Git for Windows introduced the core.hideDotFiles setting,
with three possible values: true, false, and dotGitOnly, defaulting to
marking only the .git/ directory as hidden.
The rationale: users do not need to access .git/ directly, and indeed (as
was demonstrated) should not really see that directory, either. However,
not all dot files should be hidden by default, as e.g. Eclipse does not
show them (and the user would therefore be unable to see, say, a
.gitattributes file).
In over five years since the last attempt to bring this patch into core
Git, a slightly buggy version of this patch has served Git for Windows'
users well: no single report indicated problems with the hidden .git/
directory, and the stream of problems caused by the previously non-hidden
.git/ directory simply stopped. The bugs have been fixed during the
process of getting this patch upstream.
Note that there is a funny quirk we have to pay attention to when
creating hidden files: we use Win32's _wopen() function which
transmogrifies its arguments and hands off to Win32's CreateFile()
function. That latter function errors out with ERROR_ACCESS_DENIED (the
equivalent of EACCES) when the equivalent of the O_CREAT flag was passed
and the file attributes (including the hidden flag) do not match an
existing file's. And _wopen() accepts no parameter that would be
transmogrified into said hidden flag. Therefore, we simply try again
without O_CREAT.
A slightly different method is required for our fopen()/freopen()
function as we cannot even *remove* the implicit O_CREAT flag.
Therefore, we briefly mark existing files as unhidden when opening them
via fopen()/freopen().
The ERROR_ACCESS_DENIED error can also be triggered by opening a file
that is marked as a system file (which is unlikely to be tracked in
Git), and by trying to create a file that has *just* been deleted and is
awaiting the last open handles to be released (which would be handled
better by the "Try again?" logic, a story for a different patch series,
though). In both cases, it does not matter much if we try again without
the O_CREAT flag, read: it does not hurt, either.
For details how ERROR_ACCESS_DENIED can be triggered, see
https://msdn.microsoft.com/en-us/library/windows/desktop/aa363858
Original-patch-by: Erik Faye-Lund <kusmabite@gmail.com>
Initial-Test-By: Pat Thoyts <patthoyts@users.sourceforge.net>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-11 10:43:37 +02:00
|
|
|
mkdir newdir &&
|
|
|
|
|
cd newdir &&
|
|
|
|
|
git init &&
|
|
|
|
|
is_hidden .git
|
|
|
|
|
) &&
|
|
|
|
|
check_config newdir/.git false unset
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success MINGW 'bare git dir not hidden' '
|
|
|
|
|
rm -rf newdir &&
|
|
|
|
|
(
|
2018-07-02 02:23:43 +02:00
|
|
|
sane_unset GIT_DIR GIT_WORK_TREE GIT_CONFIG &&
|
mingw: introduce the 'core.hideDotFiles' setting
On Unix (and Linux), files and directories whose names start with a dot
are usually not shown by default. This convention is used by Git: the
.git/ directory should be left alone by regular users, and only accessed
through Git itself.
On Windows, no such convention exists. Instead, there is an explicit flag
to mark files or directories as hidden.
In the early days, Git for Windows did not mark the .git/ directory (or
for that matter, any file or directory whose name starts with a dot)
hidden. This lead to quite a bit of confusion, and even loss of data.
Consequently, Git for Windows introduced the core.hideDotFiles setting,
with three possible values: true, false, and dotGitOnly, defaulting to
marking only the .git/ directory as hidden.
The rationale: users do not need to access .git/ directly, and indeed (as
was demonstrated) should not really see that directory, either. However,
not all dot files should be hidden by default, as e.g. Eclipse does not
show them (and the user would therefore be unable to see, say, a
.gitattributes file).
In over five years since the last attempt to bring this patch into core
Git, a slightly buggy version of this patch has served Git for Windows'
users well: no single report indicated problems with the hidden .git/
directory, and the stream of problems caused by the previously non-hidden
.git/ directory simply stopped. The bugs have been fixed during the
process of getting this patch upstream.
Note that there is a funny quirk we have to pay attention to when
creating hidden files: we use Win32's _wopen() function which
transmogrifies its arguments and hands off to Win32's CreateFile()
function. That latter function errors out with ERROR_ACCESS_DENIED (the
equivalent of EACCES) when the equivalent of the O_CREAT flag was passed
and the file attributes (including the hidden flag) do not match an
existing file's. And _wopen() accepts no parameter that would be
transmogrified into said hidden flag. Therefore, we simply try again
without O_CREAT.
A slightly different method is required for our fopen()/freopen()
function as we cannot even *remove* the implicit O_CREAT flag.
Therefore, we briefly mark existing files as unhidden when opening them
via fopen()/freopen().
The ERROR_ACCESS_DENIED error can also be triggered by opening a file
that is marked as a system file (which is unlikely to be tracked in
Git), and by trying to create a file that has *just* been deleted and is
awaiting the last open handles to be released (which would be handled
better by the "Try again?" logic, a story for a different patch series,
though). In both cases, it does not matter much if we try again without
the O_CREAT flag, read: it does not hurt, either.
For details how ERROR_ACCESS_DENIED can be triggered, see
https://msdn.microsoft.com/en-us/library/windows/desktop/aa363858
Original-patch-by: Erik Faye-Lund <kusmabite@gmail.com>
Initial-Test-By: Pat Thoyts <patthoyts@users.sourceforge.net>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-11 10:43:37 +02:00
|
|
|
mkdir newdir &&
|
|
|
|
|
cd newdir &&
|
|
|
|
|
git --bare init
|
|
|
|
|
) &&
|
|
|
|
|
! is_hidden newdir
|
|
|
|
|
'
|
|
|
|
|
|
config: only read .git/config from configured repos
When git_config() runs, it looks in the system, user-wide,
and repo-level config files. It gets the latter by calling
git_pathdup(), which in turn calls get_git_dir(). If we
haven't set up the git repository yet, this may simply
return ".git", and we will look at ".git/config". This
seems like it would be helpful (presumably we haven't set up
the repository yet, so it tries to find it), but it turns
out to be a bad idea for a few reasons:
- it's not sufficient, and therefore hides bugs in a
confusing way. Config will be respected if commands are
run from the top-level of the working tree, but not from
a subdirectory.
- it's not always true that we haven't set up the
repository _yet_; we may not want to do it at all. For
instance, if you run "git init /some/path" from inside
another repository, it should not load config from the
existing repository.
- there might be a path ".git/config", but it is not the
actual repository we would find via setup_git_directory().
This may happen, e.g., if you are storing a git
repository inside another git repository, but have
munged one of the files in such a way that the
inner repository is not valid (e.g., by removing HEAD).
We have at least two bugs of the second type in git-init,
introduced by ae5f677 (lazily load core.sharedrepository,
2016-03-11). It causes init to use git_configset(), which
loads all of the config, including values from the current
repo (if any). This shows up in two ways:
1. If we happen to be in an existing repository directory,
we'll read and respect core.sharedrepository from it,
even though it should have no bearing on the new
repository. A new test in t1301 covers this.
2. Similarly, if we're in an existing repo that sets
core.logallrefupdates, that will cause init to fail to
set it in a newly created repository (because it thinks
that the user's templates already did so). A new test
in t0001 covers this.
We also need to adjust an existing test in t1302, which
gives another example of why this patch is an improvement.
That test creates an embedded repository with a bogus
core.repositoryformatversion of "99". It wants to make sure
that we actually stop at the bogus repo rather than
continuing upward to find the outer repo. So it checks that
"git config core.repositoryformatversion" returns 99. But
that only works because we blindly read ".git/config", even
though we _know_ we're in a repository whose vintage we do
not understand.
After this patch, we avoid reading config from the unknown
vintage repository at all, which is a safer choice. But we
need to tweak the test, since core.repositoryformatversion
will not return 99; it will claim that it could not find the
variable at all.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-13 05:24:15 +02:00
|
|
|
test_expect_success 'remote init from does not use config from cwd' '
|
|
|
|
|
rm -rf newdir &&
|
|
|
|
|
test_config core.logallrefupdates true &&
|
|
|
|
|
git init newdir &&
|
|
|
|
|
echo true >expect &&
|
|
|
|
|
git -C newdir config --bool core.logallrefupdates >actual &&
|
|
|
|
|
test_cmp expect actual
|
|
|
|
|
'
|
|
|
|
|
|
2016-09-25 05:14:36 +02:00
|
|
|
test_expect_success 're-init from a linked worktree' '
|
|
|
|
|
git init main-worktree &&
|
|
|
|
|
(
|
|
|
|
|
cd main-worktree &&
|
|
|
|
|
test_commit first &&
|
|
|
|
|
git worktree add ../linked-worktree &&
|
|
|
|
|
mv .git/info/exclude expected-exclude &&
|
2016-09-25 05:14:39 +02:00
|
|
|
cp .git/config expected-config &&
|
2016-09-25 05:14:36 +02:00
|
|
|
find .git/worktrees -print | sort >expected &&
|
|
|
|
|
git -C ../linked-worktree init &&
|
|
|
|
|
test_cmp expected-exclude .git/info/exclude &&
|
2016-09-25 05:14:39 +02:00
|
|
|
test_cmp expected-config .git/config &&
|
2016-09-25 05:14:36 +02:00
|
|
|
find .git/worktrees -print | sort >actual &&
|
|
|
|
|
test_cmp expected actual
|
|
|
|
|
)
|
|
|
|
|
'
|
|
|
|
|
|
2017-11-01 18:10:25 +01:00
|
|
|
test_expect_success MINGW 'redirect std handles' '
|
|
|
|
|
GIT_REDIRECT_STDOUT=output.txt git rev-parse --git-dir &&
|
|
|
|
|
test .git = "$(cat output.txt)" &&
|
2017-11-01 18:10:30 +01:00
|
|
|
test -z "$(GIT_REDIRECT_STDOUT=off git rev-parse --git-dir)" &&
|
|
|
|
|
test_must_fail env \
|
|
|
|
|
GIT_REDIRECT_STDOUT=output.txt \
|
|
|
|
|
GIT_REDIRECT_STDERR="2>&1" \
|
|
|
|
|
git rev-parse --git-dir --verify refs/invalid &&
|
|
|
|
|
printf ".git\nfatal: Needed a single revision\n" >expect &&
|
|
|
|
|
test_cmp expect output.txt
|
2017-11-01 18:10:25 +01:00
|
|
|
'
|
|
|
|
|
|
2007-08-27 09:58:06 +02:00
|
|
|
test_done
|