2007-08-27 07:58:06 +00:00
|
|
|
#!/bin/sh
|
|
|
|
|
|
|
|
|
|
test_description='git init'
|
|
|
|
|
|
2021-10-12 13:56:37 +00:00
|
|
|
TEST_PASSES_SANITIZE_LEAK=true
|
2007-08-27 07:58:06 +00:00
|
|
|
. ./test-lib.sh
|
|
|
|
|
|
|
|
|
|
check_config () {
|
2022-01-21 10:21:09 +00:00
|
|
|
if test_path_is_dir "$1" &&
|
|
|
|
|
test_path_is_file "$1/config" && test_path_is_dir "$1/refs"
|
2007-08-27 07:58:06 +00:00
|
|
|
then
|
|
|
|
|
: happy
|
|
|
|
|
else
|
|
|
|
|
echo "expected a directory $1, a file $1/config and $1/refs"
|
|
|
|
|
return 1
|
|
|
|
|
fi
|
2014-11-18 13:50:24 +00:00
|
|
|
|
|
|
|
|
if test_have_prereq POSIXPERM && test -x "$1/config"
|
|
|
|
|
then
|
|
|
|
|
echo "$1/config is executable?"
|
|
|
|
|
return 1
|
|
|
|
|
fi
|
|
|
|
|
|
2014-03-20 23:15:24 +00:00
|
|
|
bare=$(cd "$1" && git config --bool core.bare)
|
|
|
|
|
worktree=$(cd "$1" && git config core.worktree) ||
|
2007-08-27 07:58:06 +00: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-20 23:23:06 +00:00
|
|
|
git init plain &&
|
2007-08-27 07:58:06 +00:00
|
|
|
check_config plain/.git false unset
|
|
|
|
|
'
|
|
|
|
|
|
2010-11-26 15:32:41 +00: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 09:37:10 +00:00
|
|
|
test_expect_success 'plain nested through aliased command' '
|
2010-11-26 15:32:41 +00: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 09:37:10 +00:00
|
|
|
test_expect_success 'plain nested in bare through aliased command' '
|
2010-11-26 15:32:41 +00: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 07:58:06 +00:00
|
|
|
'
|
|
|
|
|
|
2015-12-20 07:50:19 +00:00
|
|
|
test_expect_success 'No extra GIT_* on alias scripts' '
|
2016-03-03 06:55:17 +00:00
|
|
|
write_script script <<-\EOF &&
|
|
|
|
|
env |
|
|
|
|
|
sed -n \
|
|
|
|
|
-e "/^GIT_PREFIX=/d" \
|
|
|
|
|
-e "/^GIT_TEXTDOMAINDIR=/d" \
|
trace2: rename environment variables to GIT_TRACE2*
For an environment variable that is supposed to be set by users, the
GIT_TR2* env vars are just too unclear, inconsistent, and ugly.
Most of the established GIT_* environment variables don't use
abbreviations, and in case of the few that do (GIT_DIR,
GIT_COMMON_DIR, GIT_DIFF_OPTS) it's quite obvious what the
abbreviations (DIR and OPTS) stand for. But what does TR stand for?
Track, traditional, trailer, transaction, transfer, transformation,
transition, translation, transplant, transport, traversal, tree,
trigger, truncate, trust, or ...?!
The trace2 facility, as the '2' suffix in its name suggests, is
supposed to eventually supercede Git's original trace facility. It's
reasonable to expect that the corresponding environment variables
follow suit, and after the original GIT_TRACE variables they are
called GIT_TRACE2; there is no such thing is 'GIT_TR'.
All trace2-specific config variables are, very sensibly, in the
'trace2' section, not in 'tr2'.
OTOH, we don't gain anything at all by omitting the last three
characters of "trace" from the names of these environment variables.
So let's rename all GIT_TR2* environment variables to GIT_TRACE2*,
before they make their way into a stable release.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-19 14:43:08 +00:00
|
|
|
-e "/^GIT_TRACE2_PARENT/d" \
|
2016-03-03 06:55:17 +00:00
|
|
|
-e "/^GIT_/s/=.*//p" |
|
|
|
|
|
sort
|
2015-12-20 07:50:19 +00:00
|
|
|
EOF
|
2016-03-03 06:55:17 +00:00
|
|
|
./script >expected &&
|
2015-12-20 07:50:19 +00:00
|
|
|
git config alias.script \!./script &&
|
2016-03-03 06:55:17 +00:00
|
|
|
( mkdir sub && cd sub && git script >../actual ) &&
|
2015-12-20 07:50:19 +00:00
|
|
|
test_cmp expected actual
|
|
|
|
|
'
|
|
|
|
|
|
2007-08-27 07:58:06 +00:00
|
|
|
test_expect_success 'plain with GIT_WORK_TREE' '
|
2014-03-20 23:19:50 +00:00
|
|
|
mkdir plain-wt &&
|
|
|
|
|
test_must_fail env GIT_WORK_TREE="$(pwd)/plain-wt" git init plain-wt
|
2007-08-27 07:58:06 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'plain bare' '
|
2014-03-20 23:23:06 +00:00
|
|
|
git --bare init plain-bare-1 &&
|
2007-08-27 07:58:06 +00:00
|
|
|
check_config plain-bare-1 true unset
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'plain bare with GIT_WORK_TREE' '
|
2014-03-20 23:19:50 +00: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 07:58:06 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'GIT_DIR bare' '
|
2014-03-20 23:21:25 +00:00
|
|
|
mkdir git-dir-bare.git &&
|
|
|
|
|
GIT_DIR=git-dir-bare.git git init &&
|
2007-08-27 07:58:06 +00:00
|
|
|
check_config git-dir-bare.git true unset
|
|
|
|
|
'
|
|
|
|
|
|
2008-05-28 18:53:57 +00:00
|
|
|
test_expect_success 'init --bare' '
|
2014-03-20 23:23:06 +00:00
|
|
|
git init --bare init-bare.git &&
|
2008-07-11 00:12:03 +00:00
|
|
|
check_config init-bare.git true unset
|
2008-05-28 18:53:57 +00:00
|
|
|
'
|
|
|
|
|
|
2007-08-27 07:58:06 +00: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-20 23:19:50 +00: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 07:58:06 +00:00
|
|
|
'
|
|
|
|
|
|
2011-04-12 22:57:08 +00:00
|
|
|
test_expect_success 'reinit' '
|
2008-03-24 15:14:52 +00:00
|
|
|
|
|
|
|
|
(
|
|
|
|
|
mkdir again &&
|
|
|
|
|
cd again &&
|
2020-12-11 11:36:57 +00:00
|
|
|
git -c init.defaultBranch=initial init >out1 2>err1 &&
|
2008-03-24 15:14:52 +00:00
|
|
|
git init >out2 2>err2
|
|
|
|
|
) &&
|
2023-10-31 05:23:30 +00:00
|
|
|
test_grep "Initialized empty" again/out1 &&
|
|
|
|
|
test_grep "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 21:57:25 +00:00
|
|
|
test_must_be_empty again/err1 &&
|
|
|
|
|
test_must_be_empty again/err2
|
2008-03-24 15:14:52 +00:00
|
|
|
'
|
|
|
|
|
|
2008-07-28 06:02:04 +00:00
|
|
|
test_expect_success 'init with --template' '
|
|
|
|
|
mkdir template-source &&
|
|
|
|
|
echo content >template-source/file &&
|
2019-05-10 10:46:57 +00:00
|
|
|
git init --template=template-source template-custom &&
|
2008-07-28 06:02:04 +00:00
|
|
|
test_cmp template-source/file template-custom/.git/file
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'init with --template (blank)' '
|
2014-03-20 23:23:06 +00:00
|
|
|
git init template-plain &&
|
2014-03-20 23:17:35 +00:00
|
|
|
test_path_is_file template-plain/.git/info/exclude &&
|
2014-03-20 23:23:06 +00:00
|
|
|
git init --template= template-blank &&
|
2014-03-20 23:17:35 +00:00
|
|
|
test_path_is_missing template-blank/.git/info/exclude
|
2008-07-28 06:02:04 +00:00
|
|
|
'
|
|
|
|
|
|
init: fix bug regarding ~/ expansion in init.templateDir
We used to read the init.templateDir setting at builtin/init-db.c using
a git_config() callback that, in turn, called git_config_pathname(). To
simplify the config reading logic at this file and plug a memory leak,
this was replaced by a direct call to git_config_get_value() at
e4de4502e6 ("init: remove git_init_db_config() while fixing leaks",
2021-03-14). However, this function doesn't provide path expanding
semantics, like git_config_pathname() does, so paths with '~/' and
'~user/' are treated literally. This makes 'git init' fail to handle
init.templateDir paths using these constructs:
$ git config init.templateDir '~/templates_dir'
$ git init
'warning: templates not found in ~/templates_dir'
Replace the git_config_get_value() call by git_config_get_pathname(),
which does the '~/' and '~user/' expansions. Also add a regression test.
Note that unlike git_config_get_value(), the config cache does not own
the memory for the path returned by git_config_get_pathname(), so we
must free() it.
Reported on IRC by rkta.
Signed-off-by: Matheus Tavares <matheus.bernardino@usp.br>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-25 03:41:01 +00:00
|
|
|
init_no_templatedir_env () {
|
2010-02-26 04:00:21 +00:00
|
|
|
(
|
2010-10-03 20:00:14 +00:00
|
|
|
sane_unset GIT_TEMPLATE_DIR &&
|
2010-02-26 04:00:21 +00:00
|
|
|
NO_SET_GIT_TEMPLATE_DIR=t &&
|
|
|
|
|
export NO_SET_GIT_TEMPLATE_DIR &&
|
init: fix bug regarding ~/ expansion in init.templateDir
We used to read the init.templateDir setting at builtin/init-db.c using
a git_config() callback that, in turn, called git_config_pathname(). To
simplify the config reading logic at this file and plug a memory leak,
this was replaced by a direct call to git_config_get_value() at
e4de4502e6 ("init: remove git_init_db_config() while fixing leaks",
2021-03-14). However, this function doesn't provide path expanding
semantics, like git_config_pathname() does, so paths with '~/' and
'~user/' are treated literally. This makes 'git init' fail to handle
init.templateDir paths using these constructs:
$ git config init.templateDir '~/templates_dir'
$ git init
'warning: templates not found in ~/templates_dir'
Replace the git_config_get_value() call by git_config_get_pathname(),
which does the '~/' and '~user/' expansions. Also add a regression test.
Note that unlike git_config_get_value(), the config cache does not own
the memory for the path returned by git_config_get_pathname(), so we
must free() it.
Reported on IRC by rkta.
Signed-off-by: Matheus Tavares <matheus.bernardino@usp.br>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-25 03:41:01 +00:00
|
|
|
git init "$1"
|
|
|
|
|
)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
test_expect_success 'init with init.templatedir set' '
|
|
|
|
|
mkdir templatedir-source &&
|
|
|
|
|
echo Content >templatedir-source/file &&
|
|
|
|
|
test_config_global init.templatedir "${HOME}/templatedir-source" &&
|
|
|
|
|
|
|
|
|
|
init_no_templatedir_env templatedir-set &&
|
2010-02-26 04:00:21 +00:00
|
|
|
test_cmp templatedir-source/file templatedir-set/.git/file
|
|
|
|
|
'
|
|
|
|
|
|
init: fix bug regarding ~/ expansion in init.templateDir
We used to read the init.templateDir setting at builtin/init-db.c using
a git_config() callback that, in turn, called git_config_pathname(). To
simplify the config reading logic at this file and plug a memory leak,
this was replaced by a direct call to git_config_get_value() at
e4de4502e6 ("init: remove git_init_db_config() while fixing leaks",
2021-03-14). However, this function doesn't provide path expanding
semantics, like git_config_pathname() does, so paths with '~/' and
'~user/' are treated literally. This makes 'git init' fail to handle
init.templateDir paths using these constructs:
$ git config init.templateDir '~/templates_dir'
$ git init
'warning: templates not found in ~/templates_dir'
Replace the git_config_get_value() call by git_config_get_pathname(),
which does the '~/' and '~user/' expansions. Also add a regression test.
Note that unlike git_config_get_value(), the config cache does not own
the memory for the path returned by git_config_get_pathname(), so we
must free() it.
Reported on IRC by rkta.
Signed-off-by: Matheus Tavares <matheus.bernardino@usp.br>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-25 03:41:01 +00:00
|
|
|
test_expect_success 'init with init.templatedir using ~ expansion' '
|
|
|
|
|
mkdir -p templatedir-source &&
|
|
|
|
|
echo Content >templatedir-source/file &&
|
|
|
|
|
test_config_global init.templatedir "~/templatedir-source" &&
|
|
|
|
|
|
|
|
|
|
init_no_templatedir_env templatedir-expansion &&
|
|
|
|
|
test_cmp templatedir-source/file templatedir-expansion/.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 05:37:48 +00:00
|
|
|
test_expect_success 'init --bare/--shared overrides system/global config' '
|
2014-03-20 23:18:12 +00:00
|
|
|
test_config_global core.bare false &&
|
|
|
|
|
test_config_global core.sharedRepository 0640 &&
|
2014-03-20 23:23:06 +00: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 05:37:48 +00:00
|
|
|
check_config init-bare-shared-override true unset &&
|
|
|
|
|
test x0666 = \
|
2014-04-28 12:57:24 +00: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 05:37:48 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'init honors global core.sharedRepository' '
|
2014-03-20 23:18:12 +00:00
|
|
|
test_config_global core.sharedRepository 0666 &&
|
2014-03-20 23:23:06 +00: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 05:37:48 +00:00
|
|
|
test x0666 = \
|
2014-04-28 12:57:24 +00: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 05:37:48 +00:00
|
|
|
'
|
|
|
|
|
|
2015-10-05 03:46:04 +00:00
|
|
|
test_expect_success 'init allows insanely long --template' '
|
|
|
|
|
git init --template=$(printf "x%09999dx" 1) test
|
2009-04-18 14:14:02 +00:00
|
|
|
'
|
|
|
|
|
|
2009-07-24 21:59:28 +00:00
|
|
|
test_expect_success 'init creates a new directory' '
|
|
|
|
|
rm -fr newdir &&
|
2014-03-20 23:21:25 +00:00
|
|
|
git init newdir &&
|
|
|
|
|
test_path_is_dir newdir/.git/refs
|
2009-07-24 21:59:28 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'init creates a new bare directory' '
|
|
|
|
|
rm -fr newdir &&
|
2014-03-20 23:21:25 +00:00
|
|
|
git init --bare newdir &&
|
|
|
|
|
test_path_is_dir newdir/refs
|
2009-07-24 21:59:28 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'init recreates a directory' '
|
|
|
|
|
rm -fr newdir &&
|
2014-03-20 23:21:25 +00:00
|
|
|
mkdir newdir &&
|
|
|
|
|
git init newdir &&
|
|
|
|
|
test_path_is_dir newdir/.git/refs
|
2009-07-24 21:59:28 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'init recreates a new bare directory' '
|
|
|
|
|
rm -fr newdir &&
|
2014-03-20 23:21:25 +00:00
|
|
|
mkdir newdir &&
|
|
|
|
|
git init --bare newdir &&
|
|
|
|
|
test_path_is_dir newdir/refs
|
2009-07-24 21:59:28 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'init creates a new deep directory' '
|
2009-08-09 16:02:55 +00:00
|
|
|
rm -fr newdir &&
|
|
|
|
|
git init newdir/a/b/c &&
|
2014-03-20 23:17:35 +00:00
|
|
|
test_path_is_dir newdir/a/b/c/.git/refs
|
2009-08-09 16:02:55 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success POSIXPERM 'init creates a new deep directory (umask vs. shared)' '
|
2009-07-24 21:59:28 +00:00
|
|
|
rm -fr newdir &&
|
|
|
|
|
(
|
|
|
|
|
# Leading directories should honor umask while
|
|
|
|
|
# the repository itself should follow "shared"
|
2017-01-28 20:25:48 +00:00
|
|
|
mkdir newdir &&
|
|
|
|
|
# Remove a default ACL if possible.
|
|
|
|
|
(setfacl -k newdir 2>/dev/null || true) &&
|
2009-07-24 21:59:28 +00:00
|
|
|
umask 002 &&
|
|
|
|
|
git init --bare --shared=0660 newdir/a/b/c &&
|
2014-03-20 23:17:35 +00:00
|
|
|
test_path_is_dir newdir/a/b/c/refs &&
|
2009-07-24 21:59:28 +00:00
|
|
|
ls -ld newdir/a newdir/a/b > lsab.out &&
|
2009-08-09 15:38:04 +00:00
|
|
|
! grep -v "^drwxrw[sx]r-x" lsab.out &&
|
2009-07-24 21:59:28 +00: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-20 23:21:25 +00:00
|
|
|
>newdir &&
|
|
|
|
|
test_must_fail git init newdir &&
|
|
|
|
|
test_path_is_file newdir
|
2009-07-24 21:59:28 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'init notices EEXIST (2)' '
|
|
|
|
|
rm -fr newdir &&
|
2014-03-20 23:21:25 +00:00
|
|
|
mkdir newdir &&
|
|
|
|
|
>newdir/a &&
|
|
|
|
|
test_must_fail git init newdir/a/b &&
|
|
|
|
|
test_path_is_file newdir/a
|
2009-07-24 21:59:28 +00:00
|
|
|
'
|
|
|
|
|
|
2010-08-06 22:09:09 +00:00
|
|
|
test_expect_success POSIXPERM,SANITY 'init notices EPERM' '
|
2018-06-15 18:13:39 +00:00
|
|
|
test_when_finished "chmod +w newdir" &&
|
2009-07-24 21:59:28 +00:00
|
|
|
rm -fr newdir &&
|
2014-03-20 23:21:25 +00:00
|
|
|
mkdir newdir &&
|
|
|
|
|
chmod -w newdir &&
|
|
|
|
|
test_must_fail git init newdir/a/b
|
2009-07-24 21:59:28 +00: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 09:42:06 +00:00
|
|
|
test_expect_success 'init creates a new bare directory with global --bare' '
|
|
|
|
|
rm -rf newdir &&
|
|
|
|
|
git --bare init newdir &&
|
2014-03-20 23:17:35 +00: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 09:42:06 +00: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-20 23:17:35 +00: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 09:42:06 +00:00
|
|
|
'
|
|
|
|
|
|
2011-03-19 15:16:56 +00:00
|
|
|
test_expect_success 'init with separate gitdir' '
|
|
|
|
|
rm -rf newdir &&
|
|
|
|
|
git init --separate-git-dir realgitdir newdir &&
|
t0001: fix on case-insensitive filesystems
On a case-insensitive filesystem, such as HFS+ or NTFS, it is possible
that the idea Bash has of the current directory differs in case from
what Git thinks it is. That's totally okay, though, and we should not
expect otherwise.
On Windows, for example, when you call
cd C:\GIT-SDK-64
in a PowerShell and there exists a directory called `C:\git-sdk-64`, the
current directory will be reported in all upper-case. Even in a Bash
that you might call from that PowerShell. Git, however, will have
normalized this via `GetFinalPathByHandle()`, and the expectation in
t0001 that the recorded gitdir will match what `pwd` says will be
violated.
Let's address this by comparing these paths in a case-insensitive
manner when `core.ignoreCase` is `true`.
Reported by Jameson Miller.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-24 17:40:05 +00:00
|
|
|
newdir_git="$(cat newdir/.git)" &&
|
|
|
|
|
test_cmp_fspath "$(pwd)/realgitdir" "${newdir_git#gitdir: }" &&
|
2014-03-20 23:17:35 +00:00
|
|
|
test_path_is_dir realgitdir/refs
|
2011-03-19 15:16:56 +00:00
|
|
|
'
|
|
|
|
|
|
init: disallow --separate-git-dir with bare repository
The purpose of "git init --separate-git-dir" is to separate the
repository from the worktree. This is true even when --separate-git-dir
is used on an existing worktree, in which case, it moves the .git/
subdirectory to a new location outside the worktree.
However, an outright bare repository (such as one created by "git init
--bare"), has no worktree, so using --separate-git-dir to separate it
from its non-existent worktree is nonsensical. Therefore, make it an
error to use --separate-git-dir on a bare repository.
Implementation note: "git init" considers a repository bare if told so
explicitly via --bare or if it guesses it to be so based upon
heuristics. In the explicit --bare case, a conflict with
--separate-git-dir is easy to detect early. In the guessed case,
however, the conflict can only be detected once "bareness" is guessed,
which happens after "git init" has begun creating the repository.
Technically, we can get by with a single late check which would cover
both cases, however, erroring out early, when possible, without leaving
detritus provides a better user experience.
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-09 22:53:16 +00:00
|
|
|
test_expect_success 'explicit bare & --separate-git-dir incompatible' '
|
|
|
|
|
test_must_fail git init --bare --separate-git-dir goop.git bare.git 2>err &&
|
2023-10-31 05:23:30 +00:00
|
|
|
test_grep "cannot be used together" err
|
init: disallow --separate-git-dir with bare repository
The purpose of "git init --separate-git-dir" is to separate the
repository from the worktree. This is true even when --separate-git-dir
is used on an existing worktree, in which case, it moves the .git/
subdirectory to a new location outside the worktree.
However, an outright bare repository (such as one created by "git init
--bare"), has no worktree, so using --separate-git-dir to separate it
from its non-existent worktree is nonsensical. Therefore, make it an
error to use --separate-git-dir on a bare repository.
Implementation note: "git init" considers a repository bare if told so
explicitly via --bare or if it guesses it to be so based upon
heuristics. In the explicit --bare case, a conflict with
--separate-git-dir is easy to detect early. In the guessed case,
however, the conflict can only be detected once "bareness" is guessed,
which happens after "git init" has begun creating the repository.
Technically, we can get by with a single late check which would cover
both cases, however, erroring out early, when possible, without leaving
detritus provides a better user experience.
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-09 22:53:16 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'implicit bare & --separate-git-dir incompatible' '
|
|
|
|
|
test_when_finished "rm -rf bare.git" &&
|
|
|
|
|
mkdir -p bare.git &&
|
|
|
|
|
test_must_fail env GIT_DIR=. \
|
|
|
|
|
git -C bare.git init --separate-git-dir goop.git 2>err &&
|
2023-10-31 05:23:30 +00:00
|
|
|
test_grep "incompatible" err
|
init: disallow --separate-git-dir with bare repository
The purpose of "git init --separate-git-dir" is to separate the
repository from the worktree. This is true even when --separate-git-dir
is used on an existing worktree, in which case, it moves the .git/
subdirectory to a new location outside the worktree.
However, an outright bare repository (such as one created by "git init
--bare"), has no worktree, so using --separate-git-dir to separate it
from its non-existent worktree is nonsensical. Therefore, make it an
error to use --separate-git-dir on a bare repository.
Implementation note: "git init" considers a repository bare if told so
explicitly via --bare or if it guesses it to be so based upon
heuristics. In the explicit --bare case, a conflict with
--separate-git-dir is easy to detect early. In the guessed case,
however, the conflict can only be detected once "bareness" is guessed,
which happens after "git init" has begun creating the repository.
Technically, we can get by with a single late check which would cover
both cases, however, erroring out early, when possible, without leaving
detritus provides a better user experience.
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-09 22:53:16 +00:00
|
|
|
'
|
|
|
|
|
|
2020-08-31 06:58:00 +00:00
|
|
|
test_expect_success 'bare & --separate-git-dir incompatible within worktree' '
|
|
|
|
|
test_when_finished "rm -rf bare.git linkwt seprepo" &&
|
|
|
|
|
test_commit gumby &&
|
|
|
|
|
git clone --bare . bare.git &&
|
|
|
|
|
git -C bare.git worktree add --detach ../linkwt &&
|
|
|
|
|
test_must_fail git -C linkwt init --separate-git-dir seprepo 2>err &&
|
2023-10-31 05:23:30 +00:00
|
|
|
test_grep "incompatible" err
|
2020-08-31 06:58:00 +00:00
|
|
|
'
|
|
|
|
|
|
2017-08-07 11:04:18 +00: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 13:13:26 +00:00
|
|
|
BUG "cannot prepare $base"
|
2017-08-07 11:04:18 +00:00
|
|
|
|
2021-07-30 16:18:14 +00:00
|
|
|
(
|
|
|
|
|
cd $base/dir &&
|
|
|
|
|
test-tool getcwd
|
|
|
|
|
)
|
2017-08-07 11:04:18 +00:00
|
|
|
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 13:13:26 +00:00
|
|
|
BUG "cannot clean $base"
|
2017-08-07 11:04:18 +00:00
|
|
|
return $status
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
check_long_base_path () {
|
2017-03-26 13:43:50 +00: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 11:04:18 +00:00
|
|
|
if test $# = 1
|
|
|
|
|
then
|
|
|
|
|
chmod $1 $component
|
|
|
|
|
fi &&
|
2017-03-26 13:43:50 +00:00
|
|
|
(
|
|
|
|
|
cd $p127 &&
|
|
|
|
|
git init newdir
|
|
|
|
|
)
|
2017-08-07 11:04:18 +00: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 13:43:50 +00:00
|
|
|
'
|
|
|
|
|
|
2013-08-31 01:04:14 +00:00
|
|
|
test_expect_success 're-init on .git file' '
|
|
|
|
|
( cd newdir && git init )
|
|
|
|
|
'
|
|
|
|
|
|
2011-03-19 15:16:56 +00:00
|
|
|
test_expect_success 're-init to update git link' '
|
t0001: fix on case-insensitive filesystems
On a case-insensitive filesystem, such as HFS+ or NTFS, it is possible
that the idea Bash has of the current directory differs in case from
what Git thinks it is. That's totally okay, though, and we should not
expect otherwise.
On Windows, for example, when you call
cd C:\GIT-SDK-64
in a PowerShell and there exists a directory called `C:\git-sdk-64`, the
current directory will be reported in all upper-case. Even in a Bash
that you might call from that PowerShell. Git, however, will have
normalized this via `GetFinalPathByHandle()`, and the expectation in
t0001 that the recorded gitdir will match what `pwd` says will be
violated.
Let's address this by comparing these paths in a case-insensitive
manner when `core.ignoreCase` is `true`.
Reported by Jameson Miller.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-24 17:40:05 +00:00
|
|
|
git -C newdir init --separate-git-dir ../surrealgitdir &&
|
|
|
|
|
newdir_git="$(cat newdir/.git)" &&
|
|
|
|
|
test_cmp_fspath "$(pwd)/surrealgitdir" "${newdir_git#gitdir: }" &&
|
2014-03-20 23:17:35 +00:00
|
|
|
test_path_is_dir surrealgitdir/refs &&
|
|
|
|
|
test_path_is_missing realgitdir/refs
|
2011-03-19 15:16:56 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 're-init to move gitdir' '
|
|
|
|
|
rm -rf newdir realgitdir surrealgitdir &&
|
|
|
|
|
git init newdir &&
|
t0001: fix on case-insensitive filesystems
On a case-insensitive filesystem, such as HFS+ or NTFS, it is possible
that the idea Bash has of the current directory differs in case from
what Git thinks it is. That's totally okay, though, and we should not
expect otherwise.
On Windows, for example, when you call
cd C:\GIT-SDK-64
in a PowerShell and there exists a directory called `C:\git-sdk-64`, the
current directory will be reported in all upper-case. Even in a Bash
that you might call from that PowerShell. Git, however, will have
normalized this via `GetFinalPathByHandle()`, and the expectation in
t0001 that the recorded gitdir will match what `pwd` says will be
violated.
Let's address this by comparing these paths in a case-insensitive
manner when `core.ignoreCase` is `true`.
Reported by Jameson Miller.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-24 17:40:05 +00:00
|
|
|
git -C newdir init --separate-git-dir ../realgitdir &&
|
|
|
|
|
newdir_git="$(cat newdir/.git)" &&
|
|
|
|
|
test_cmp_fspath "$(pwd)/realgitdir" "${newdir_git#gitdir: }" &&
|
2014-03-20 23:17:35 +00:00
|
|
|
test_path_is_dir realgitdir/refs
|
2011-03-19 15:16:56 +00:00
|
|
|
'
|
|
|
|
|
|
2011-04-12 06:30:49 +00:00
|
|
|
test_expect_success SYMLINKS 're-init to move gitdir symlink' '
|
2011-03-19 15:16:56 +00:00
|
|
|
rm -rf newdir realgitdir &&
|
|
|
|
|
git init newdir &&
|
|
|
|
|
(
|
|
|
|
|
cd newdir &&
|
|
|
|
|
mv .git here &&
|
|
|
|
|
ln -s here .git &&
|
2011-05-24 16:40:32 +00:00
|
|
|
git init --separate-git-dir ../realgitdir
|
2011-03-19 15:16:56 +00:00
|
|
|
) &&
|
2014-04-28 12:57:24 +00:00
|
|
|
echo "gitdir: $(pwd)/realgitdir" >expected &&
|
2011-03-19 15:16:56 +00:00
|
|
|
test_cmp expected newdir/.git &&
|
2014-03-20 23:17:15 +00:00
|
|
|
test_cmp expected newdir/here &&
|
2014-03-20 23:17:35 +00:00
|
|
|
test_path_is_dir realgitdir/refs
|
2011-03-19 15:16:56 +00:00
|
|
|
'
|
|
|
|
|
|
2020-08-31 06:58:00 +00:00
|
|
|
sep_git_dir_worktree () {
|
2020-08-31 06:57:59 +00:00
|
|
|
test_when_finished "rm -rf mainwt linkwt seprepo" &&
|
|
|
|
|
git init mainwt &&
|
|
|
|
|
test_commit -C mainwt gumby &&
|
|
|
|
|
git -C mainwt worktree add --detach ../linkwt &&
|
2020-08-31 06:58:00 +00:00
|
|
|
git -C "$1" init --separate-git-dir ../seprepo &&
|
2020-08-31 06:57:59 +00:00
|
|
|
git -C mainwt rev-parse --git-common-dir >expect &&
|
|
|
|
|
git -C linkwt rev-parse --git-common-dir >actual &&
|
|
|
|
|
test_cmp expect actual
|
2020-08-31 06:58:00 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
test_expect_success 're-init to move gitdir with linked worktrees' '
|
|
|
|
|
sep_git_dir_worktree mainwt
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 're-init to move gitdir within linked worktree' '
|
|
|
|
|
sep_git_dir_worktree linkwt
|
2020-08-31 06:57:59 +00: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 08:43:37 +00:00
|
|
|
test_expect_success MINGW '.git hidden' '
|
|
|
|
|
rm -rf newdir &&
|
|
|
|
|
(
|
2018-07-02 00:23:43 +00: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 08:43:37 +00:00
|
|
|
mkdir newdir &&
|
|
|
|
|
cd newdir &&
|
|
|
|
|
git init &&
|
2020-04-11 13:40:22 +00:00
|
|
|
test_path_is_hidden .git
|
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 08:43:37 +00:00
|
|
|
) &&
|
|
|
|
|
check_config newdir/.git false unset
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success MINGW 'bare git dir not hidden' '
|
|
|
|
|
rm -rf newdir &&
|
|
|
|
|
(
|
2018-07-02 00:23:43 +00: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 08:43:37 +00: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 03:24:15 +00: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 03:14:36 +00: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 03:14:39 +00:00
|
|
|
cp .git/config expected-config &&
|
2016-09-25 03:14:36 +00:00
|
|
|
find .git/worktrees -print | sort >expected &&
|
|
|
|
|
git -C ../linked-worktree init &&
|
|
|
|
|
test_cmp expected-exclude .git/info/exclude &&
|
2016-09-25 03:14:39 +00:00
|
|
|
test_cmp expected-config .git/config &&
|
2016-09-25 03:14:36 +00:00
|
|
|
find .git/worktrees -print | sort >actual &&
|
|
|
|
|
test_cmp expected actual
|
|
|
|
|
)
|
|
|
|
|
'
|
|
|
|
|
|
2020-07-29 23:14:22 +00:00
|
|
|
test_expect_success 'init honors GIT_DEFAULT_HASH' '
|
|
|
|
|
GIT_DEFAULT_HASH=sha1 git init sha1 &&
|
|
|
|
|
git -C sha1 rev-parse --show-object-format >actual &&
|
|
|
|
|
echo sha1 >expected &&
|
|
|
|
|
test_cmp expected actual &&
|
|
|
|
|
GIT_DEFAULT_HASH=sha256 git init sha256 &&
|
|
|
|
|
git -C sha256 rev-parse --show-object-format >actual &&
|
|
|
|
|
echo sha256 >expected &&
|
|
|
|
|
test_cmp expected actual
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'init honors --object-format' '
|
|
|
|
|
git init --object-format=sha1 explicit-sha1 &&
|
|
|
|
|
git -C explicit-sha1 rev-parse --show-object-format >actual &&
|
|
|
|
|
echo sha1 >expected &&
|
|
|
|
|
test_cmp expected actual &&
|
|
|
|
|
git init --object-format=sha256 explicit-sha256 &&
|
|
|
|
|
git -C explicit-sha256 rev-parse --show-object-format >actual &&
|
|
|
|
|
echo sha256 >expected &&
|
|
|
|
|
test_cmp expected actual
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'extensions.objectFormat is not allowed with repo version 0' '
|
|
|
|
|
git init --object-format=sha256 explicit-v0 &&
|
|
|
|
|
git -C explicit-v0 config core.repositoryformatversion 0 &&
|
|
|
|
|
test_must_fail git -C explicit-v0 rev-parse --show-object-format
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'init rejects attempts to initialize with different hash' '
|
|
|
|
|
test_must_fail git -C sha1 init --object-format=sha256 &&
|
|
|
|
|
test_must_fail git -C sha256 init --object-format=sha1
|
|
|
|
|
'
|
|
|
|
|
|
2019-03-11 20:10:58 +00:00
|
|
|
test_expect_success MINGW 'core.hidedotfiles = false' '
|
|
|
|
|
git config --global core.hidedotfiles false &&
|
|
|
|
|
rm -rf newdir &&
|
|
|
|
|
mkdir newdir &&
|
|
|
|
|
(
|
|
|
|
|
sane_unset GIT_DIR GIT_WORK_TREE GIT_CONFIG &&
|
|
|
|
|
git -C newdir init
|
|
|
|
|
) &&
|
|
|
|
|
! is_hidden newdir/.git
|
|
|
|
|
'
|
|
|
|
|
|
2017-11-01 17:10:25 +00: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 17:10:30 +00: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 &&
|
2019-06-19 21:05:57 +00:00
|
|
|
grep "^\\.git\$" output.txt &&
|
|
|
|
|
grep "Needed a single revision" output.txt
|
2017-11-01 17:10:25 +00:00
|
|
|
'
|
|
|
|
|
|
2020-06-24 14:46:32 +00:00
|
|
|
test_expect_success '--initial-branch' '
|
|
|
|
|
git init --initial-branch=hello initial-branch-option &&
|
|
|
|
|
git -C initial-branch-option symbolic-ref HEAD >actual &&
|
|
|
|
|
echo refs/heads/hello >expect &&
|
|
|
|
|
test_cmp expect actual &&
|
|
|
|
|
|
|
|
|
|
: re-initializing should not change the branch name &&
|
|
|
|
|
git init --initial-branch=ignore initial-branch-option 2>err &&
|
2023-10-31 05:23:30 +00:00
|
|
|
test_grep "ignored --initial-branch" err &&
|
2020-06-24 14:46:32 +00:00
|
|
|
git -C initial-branch-option symbolic-ref HEAD >actual &&
|
|
|
|
|
grep hello actual
|
|
|
|
|
'
|
|
|
|
|
|
2020-06-24 14:46:33 +00:00
|
|
|
test_expect_success 'overridden default initial branch name (config)' '
|
|
|
|
|
test_config_global init.defaultBranch nmb &&
|
2020-10-23 14:00:00 +00:00
|
|
|
GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME= git init initial-branch-config &&
|
2020-06-24 14:46:33 +00:00
|
|
|
git -C initial-branch-config symbolic-ref HEAD >actual &&
|
|
|
|
|
grep nmb actual
|
|
|
|
|
'
|
|
|
|
|
|
2020-12-11 11:36:57 +00:00
|
|
|
test_expect_success 'advice on unconfigured init.defaultBranch' '
|
|
|
|
|
GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME= git -c color.advice=always \
|
|
|
|
|
init unconfigured-default-branch-name 2>err &&
|
|
|
|
|
test_decode_color <err >decoded &&
|
2023-10-31 05:23:30 +00:00
|
|
|
test_grep "<YELLOW>hint: " decoded
|
2020-12-11 11:36:57 +00:00
|
|
|
'
|
|
|
|
|
|
2020-10-23 14:00:00 +00:00
|
|
|
test_expect_success 'overridden default main branch name (env)' '
|
|
|
|
|
test_config_global init.defaultBranch nmb &&
|
|
|
|
|
GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=env git init main-branch-env &&
|
|
|
|
|
git -C main-branch-env symbolic-ref HEAD >actual &&
|
|
|
|
|
grep env actual
|
|
|
|
|
'
|
|
|
|
|
|
2020-06-24 14:46:33 +00:00
|
|
|
test_expect_success 'invalid default branch name' '
|
2020-10-23 14:00:00 +00:00
|
|
|
test_must_fail env GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME="with space" \
|
|
|
|
|
git init initial-branch-invalid 2>err &&
|
2023-10-31 05:23:30 +00:00
|
|
|
test_grep "invalid branch name" err
|
2020-06-24 14:46:33 +00:00
|
|
|
'
|
|
|
|
|
|
2020-12-11 11:36:55 +00:00
|
|
|
test_expect_success 'branch -m with the initial branch' '
|
|
|
|
|
git init rename-initial &&
|
|
|
|
|
git -C rename-initial branch -m renamed &&
|
2023-02-06 22:44:31 +00:00
|
|
|
echo renamed >expect &&
|
|
|
|
|
git -C rename-initial symbolic-ref --short HEAD >actual &&
|
|
|
|
|
test_cmp expect actual &&
|
|
|
|
|
|
2020-12-11 11:36:55 +00:00
|
|
|
git -C rename-initial branch -m renamed again &&
|
2023-02-06 22:44:31 +00:00
|
|
|
echo again >expect &&
|
|
|
|
|
git -C rename-initial symbolic-ref --short HEAD >actual &&
|
|
|
|
|
test_cmp expect actual
|
2020-12-11 11:36:55 +00:00
|
|
|
'
|
|
|
|
|
|
2007-08-27 07:58:06 +00:00
|
|
|
test_done
|