mirrors/git
1
0
Fork 0
mirror of https://github.com/git/git.git synced 2024-11-05 00:37:55 +01:00
Code Activity
git/t/t0001-init.sh

343 lines
8.3 KiB
Bash
Raw Normal View History

Fix initialization of a bare repository Here is my attempt to fix this with a minimally intrusive patch. * As "git --bare init" cannot tell if it was called with --bare or just "GIT_DIR=. git init", I added an explicit assignment of is_bare_repository_cfg on the codepath for "git --bare". * GIT_WORK_TREE alone without GIT_DIR does not make any sense, nor GIT_WORK_TREE with an explicit "git --bare". Catch that mistake. It might make sense to move this check to "git.c" side as well, but I tried to shoot for the minimum change for now. * Some scripts, especially from the olden days, rely on traditional GIT_DIR behaviour in "git init". Namely, these are some notable patterns: (create a bare repository) - mkdir some.git && cd some.git && GIT_DIR=. git init - mkdir some.git && cd some.git && git --bare init (create a non-bare repository) - mkdir .git && GIT_DIR=.git git init - mkdir .git && GIT_DIR=`pwd`/.git git init This comes with a new test script and also passes the existing test suite, but there may be cases that are still broken with the current tip of master and this patch does not yet fix. I'd appreciate help in straightening this mess out. Signed-off-by: Junio C Hamano <gitster@pobox.com>
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
create_default_files(): don't set u+x bit on $GIT_DIR/config Since time immemorial, the test of whether to set "core.filemode" has been done by trying to toggle the u+x bit on $GIT_DIR/config, which we know always exists, and then testing whether the change "took". I find it somewhat odd to use the config file for this test, but whatever. The test code didn't set the u+x bit back to its original state itself, instead relying on the subsequent call to git_config_set() to re-write the config file with correct permissions. But ever since daa22c6f8d config: preserve config file permissions on edits (2014-05-06) git_config_set() copies the permissions from the old config file to the new one. This is a good change in and of itself, but it invalidates the create_default_files()'s assumption, causing "git init" to leave the executable bit set on $GIT_DIR/config. Reset the permissions on $GIT_DIR/config when we are done with the test in create_default_files(). Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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
t: stop using GIT_CONFIG to cross repo boundaries Some tests want to check or set config in another repository. E.g., t1000 creates repositories and makes sure that their core.bare and core.worktree settings are what we expect. We can do this with: GIT_CONFIG=$repo/.git/config git config ... but it better shows the intent to just enter the repository and let "git config" do the normal lookups: (cd $repo && git config ...) In theory, this would cause us to use an extra subshell, but in all such cases, we are actually already in a subshell. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-21 00:15:24 +01:00
bare=$(cd "$1" && git config --bool core.bare)
worktree=$(cd "$1" && git config core.worktree) ||
Fix initialization of a bare repository Here is my attempt to fix this with a minimally intrusive patch. * As "git --bare init" cannot tell if it was called with --bare or just "GIT_DIR=. git init", I added an explicit assignment of is_bare_repository_cfg on the codepath for "git --bare". * GIT_WORK_TREE alone without GIT_DIR does not make any sense, nor GIT_WORK_TREE with an explicit "git --bare". Catch that mistake. It might make sense to move this check to "git.c" side as well, but I tried to shoot for the minimum change for now. * Some scripts, especially from the olden days, rely on traditional GIT_DIR behaviour in "git init". Namely, these are some notable patterns: (create a bare repository) - mkdir some.git && cd some.git && GIT_DIR=. git init - mkdir some.git && cd some.git && git --bare init (create a non-bare repository) - mkdir .git && GIT_DIR=.git git init - mkdir .git && GIT_DIR=`pwd`/.git git init This comes with a new test script and also passes the existing test suite, but there may be cases that are still broken with the current tip of master and this patch does not yet fix. I'd appreciate help in straightening this mess out. Signed-off-by: Junio C Hamano <gitster@pobox.com>
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' '
t0001: drop subshells just for "cd" Many tests do something like: ( mkdir foo && cd foo && git init ) You can do the same these days with "git init foo", which makes the tests shorter and simpler to read. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-21 00:23:06 +01:00
git init plain &&
Fix initialization of a bare repository Here is my attempt to fix this with a minimally intrusive patch. * As "git --bare init" cannot tell if it was called with --bare or just "GIT_DIR=. git init", I added an explicit assignment of is_bare_repository_cfg on the codepath for "git --bare". * GIT_WORK_TREE alone without GIT_DIR does not make any sense, nor GIT_WORK_TREE with an explicit "git --bare". Catch that mistake. It might make sense to move this check to "git.c" side as well, but I tried to shoot for the minimum change for now. * Some scripts, especially from the olden days, rely on traditional GIT_DIR behaviour in "git init". Namely, these are some notable patterns: (create a bare repository) - mkdir some.git && cd some.git && GIT_DIR=. git init - mkdir some.git && cd some.git && git --bare init (create a non-bare repository) - mkdir .git && GIT_DIR=.git git init - mkdir .git && GIT_DIR=`pwd`/.git git init This comes with a new test script and also passes the existing test suite, but there may be cases that are still broken with the current tip of master and this patch does not yet fix. I'd appreciate help in straightening this mess out. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-08-27 09:58:06 +02:00
check_config plain/.git false unset
'
t0001: test git init when run via an alias Add some tests to document the correct behavior of (possibly aliased) init when run within and outside a git directory. If I set up a simple git alias “quietinit = init --quiet”, usually it will work just like ‘git init --quiet’. There are some differences, unfortunately, since in the process of checking for aliases, git has to look for a .git/config file. If ‘git quietinit’ is run from a subdirectory of an existing git repository, that repository’s configuration will affect the configuration of the new repository. In particular, the new repository can inherit bogus values for core.bare and core.worktree. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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
'
git potty: restore environments after alias expansion Commit 4ad8332 (t0001: test git init when run via an alias - 2010-11-26) noted breakages when running init via alias. The problem is for alias to be used, $GIT_DIR must be searched, but 'init' and 'clone' are not happy with that. So we start a new process like an external command, with clean environment in this case. Env variables that are set by command line (e.g. "git --git-dir=.. ") are kept. This should also fix autocorrecting a command typo to "init" because it's the same problem: aliases are read, then "init" is unhappy with $GIT_DIR already set up because of that. Reminded-by: David Turner <dturner@twopensource.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-08 11:37:10 +02:00
test_expect_success 'plain nested through aliased command' '
t0001: test git init when run via an alias Add some tests to document the correct behavior of (possibly aliased) init when run within and outside a git directory. If I set up a simple git alias “quietinit = init --quiet”, usually it will work just like ‘git init --quiet’. There are some differences, unfortunately, since in the process of checking for aliases, git has to look for a .git/config file. If ‘git quietinit’ is run from a subdirectory of an existing git repository, that repository’s configuration will affect the configuration of the new repository. In particular, the new repository can inherit bogus values for core.bare and core.worktree. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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
'
git potty: restore environments after alias expansion Commit 4ad8332 (t0001: test git init when run via an alias - 2010-11-26) noted breakages when running init via alias. The problem is for alias to be used, $GIT_DIR must be searched, but 'init' and 'clone' are not happy with that. So we start a new process like an external command, with clean environment in this case. Env variables that are set by command line (e.g. "git --git-dir=.. ") are kept. This should also fix autocorrecting a command typo to "init" because it's the same problem: aliases are read, then "init" is unhappy with $GIT_DIR already set up because of that. Reminded-by: David Turner <dturner@twopensource.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-08 11:37:10 +02:00
test_expect_success 'plain nested in bare through aliased command' '
t0001: test git init when run via an alias Add some tests to document the correct behavior of (possibly aliased) init when run within and outside a git directory. If I set up a simple git alias “quietinit = init --quiet”, usually it will work just like ‘git init --quiet’. There are some differences, unfortunately, since in the process of checking for aliases, git has to look for a .git/config file. If ‘git quietinit’ is run from a subdirectory of an existing git repository, that repository’s configuration will affect the configuration of the new repository. In particular, the new repository can inherit bogus values for core.bare and core.worktree. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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
Fix initialization of a bare repository Here is my attempt to fix this with a minimally intrusive patch. * As "git --bare init" cannot tell if it was called with --bare or just "GIT_DIR=. git init", I added an explicit assignment of is_bare_repository_cfg on the codepath for "git --bare". * GIT_WORK_TREE alone without GIT_DIR does not make any sense, nor GIT_WORK_TREE with an explicit "git --bare". Catch that mistake. It might make sense to move this check to "git.c" side as well, but I tried to shoot for the minimum change for now. * Some scripts, especially from the olden days, rely on traditional GIT_DIR behaviour in "git init". Namely, these are some notable patterns: (create a bare repository) - mkdir some.git && cd some.git && GIT_DIR=. git init - mkdir some.git && cd some.git && git --bare init (create a non-bare repository) - mkdir .git && GIT_DIR=.git git init - mkdir .git && GIT_DIR=`pwd`/.git git init This comes with a new test script and also passes the existing test suite, but there may be cases that are still broken with the current tip of master and this patch does not yet fix. I'd appreciate help in straightening this mess out. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-08-27 09:58:06 +02:00
'
test_expect_success 'plain with GIT_WORK_TREE' '
t0001: use test_must_fail We've hand-rolled several "if" statements looking for failures. We can use test_must_fail here, which is shorter and more robust. Note that we modify the commands slightly (to use "git init foo" rather than "cd foo && git init") to avoid dealing with a subshell, but this should not affect the outcome. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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
Fix initialization of a bare repository Here is my attempt to fix this with a minimally intrusive patch. * As "git --bare init" cannot tell if it was called with --bare or just "GIT_DIR=. git init", I added an explicit assignment of is_bare_repository_cfg on the codepath for "git --bare". * GIT_WORK_TREE alone without GIT_DIR does not make any sense, nor GIT_WORK_TREE with an explicit "git --bare". Catch that mistake. It might make sense to move this check to "git.c" side as well, but I tried to shoot for the minimum change for now. * Some scripts, especially from the olden days, rely on traditional GIT_DIR behaviour in "git init". Namely, these are some notable patterns: (create a bare repository) - mkdir some.git && cd some.git && GIT_DIR=. git init - mkdir some.git && cd some.git && git --bare init (create a non-bare repository) - mkdir .git && GIT_DIR=.git git init - mkdir .git && GIT_DIR=`pwd`/.git git init This comes with a new test script and also passes the existing test suite, but there may be cases that are still broken with the current tip of master and this patch does not yet fix. I'd appreciate help in straightening this mess out. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-08-27 09:58:06 +02:00
'
test_expect_success 'plain bare' '
t0001: drop subshells just for "cd" Many tests do something like: ( mkdir foo && cd foo && git init ) You can do the same these days with "git init foo", which makes the tests shorter and simpler to read. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-21 00:23:06 +01:00
git --bare init plain-bare-1 &&
Fix initialization of a bare repository Here is my attempt to fix this with a minimally intrusive patch. * As "git --bare init" cannot tell if it was called with --bare or just "GIT_DIR=. git init", I added an explicit assignment of is_bare_repository_cfg on the codepath for "git --bare". * GIT_WORK_TREE alone without GIT_DIR does not make any sense, nor GIT_WORK_TREE with an explicit "git --bare". Catch that mistake. It might make sense to move this check to "git.c" side as well, but I tried to shoot for the minimum change for now. * Some scripts, especially from the olden days, rely on traditional GIT_DIR behaviour in "git init". Namely, these are some notable patterns: (create a bare repository) - mkdir some.git && cd some.git && GIT_DIR=. git init - mkdir some.git && cd some.git && git --bare init (create a non-bare repository) - mkdir .git && GIT_DIR=.git git init - mkdir .git && GIT_DIR=`pwd`/.git git init This comes with a new test script and also passes the existing test suite, but there may be cases that are still broken with the current tip of master and this patch does not yet fix. I'd appreciate help in straightening this mess out. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-08-27 09:58:06 +02:00
check_config plain-bare-1 true unset
'
test_expect_success 'plain bare with GIT_WORK_TREE' '
t0001: use test_must_fail We've hand-rolled several "if" statements looking for failures. We can use test_must_fail here, which is shorter and more robust. Note that we modify the commands slightly (to use "git init foo" rather than "cd foo && git init") to avoid dealing with a subshell, but this should not affect the outcome. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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
Fix initialization of a bare repository Here is my attempt to fix this with a minimally intrusive patch. * As "git --bare init" cannot tell if it was called with --bare or just "GIT_DIR=. git init", I added an explicit assignment of is_bare_repository_cfg on the codepath for "git --bare". * GIT_WORK_TREE alone without GIT_DIR does not make any sense, nor GIT_WORK_TREE with an explicit "git --bare". Catch that mistake. It might make sense to move this check to "git.c" side as well, but I tried to shoot for the minimum change for now. * Some scripts, especially from the olden days, rely on traditional GIT_DIR behaviour in "git init". Namely, these are some notable patterns: (create a bare repository) - mkdir some.git && cd some.git && GIT_DIR=. git init - mkdir some.git && cd some.git && git --bare init (create a non-bare repository) - mkdir .git && GIT_DIR=.git git init - mkdir .git && GIT_DIR=`pwd`/.git git init This comes with a new test script and also passes the existing test suite, but there may be cases that are still broken with the current tip of master and this patch does not yet fix. I'd appreciate help in straightening this mess out. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-08-27 09:58:06 +02:00
'
test_expect_success 'GIT_DIR bare' '
t0001: drop useless subshells Many tests use subshells, but don't actually change the shell environment. They were probably cargo-culted from earlier tests which did need subshells. Drop the useless ones. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-21 00:21:25 +01:00
mkdir git-dir-bare.git &&
GIT_DIR=git-dir-bare.git git init &&
Fix initialization of a bare repository Here is my attempt to fix this with a minimally intrusive patch. * As "git --bare init" cannot tell if it was called with --bare or just "GIT_DIR=. git init", I added an explicit assignment of is_bare_repository_cfg on the codepath for "git --bare". * GIT_WORK_TREE alone without GIT_DIR does not make any sense, nor GIT_WORK_TREE with an explicit "git --bare". Catch that mistake. It might make sense to move this check to "git.c" side as well, but I tried to shoot for the minimum change for now. * Some scripts, especially from the olden days, rely on traditional GIT_DIR behaviour in "git init". Namely, these are some notable patterns: (create a bare repository) - mkdir some.git && cd some.git && GIT_DIR=. git init - mkdir some.git && cd some.git && git --bare init (create a non-bare repository) - mkdir .git && GIT_DIR=.git git init - mkdir .git && GIT_DIR=`pwd`/.git git init This comes with a new test script and also passes the existing test suite, but there may be cases that are still broken with the current tip of master and this patch does not yet fix. I'd appreciate help in straightening this mess out. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-08-27 09:58:06 +02:00
check_config git-dir-bare.git true unset
'
git-init: accept --bare option It is unfortunate that "git init --bare" does not work and the only reason why "init" did not learn its own "--bare" option is because "git --bare init" already does the job (and as an option to the git 'potty', it is more generic solution). This teaches "git init" its own "--bare" option, so that both "git --bare init" and "git init --bare" works mostly the same way. [jc: rewrote the log message and added test] Signed-off-by: Luciano Rocha <strange@nsk.pt> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-28 20:53:57 +02:00
test_expect_success 'init --bare' '
t0001: drop subshells just for "cd" Many tests do something like: ( mkdir foo && cd foo && git init ) You can do the same these days with "git init foo", which makes the tests shorter and simpler to read. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-21 00:23:06 +01:00
git init --bare init-bare.git &&
t0001-init.sh: change confusing directory name using git-init as directory name confused 'make remove-dashes', so just drop the 'git-' prefix. Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-11 02:12:03 +02:00
check_config init-bare.git true unset
git-init: accept --bare option It is unfortunate that "git init --bare" does not work and the only reason why "init" did not learn its own "--bare" option is because "git --bare init" already does the job (and as an option to the git 'potty', it is more generic solution). This teaches "git init" its own "--bare" option, so that both "git --bare init" and "git init --bare" works mostly the same way. [jc: rewrote the log message and added test] Signed-off-by: Luciano Rocha <strange@nsk.pt> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-28 20:53:57 +02:00
'
Fix initialization of a bare repository Here is my attempt to fix this with a minimally intrusive patch. * As "git --bare init" cannot tell if it was called with --bare or just "GIT_DIR=. git init", I added an explicit assignment of is_bare_repository_cfg on the codepath for "git --bare". * GIT_WORK_TREE alone without GIT_DIR does not make any sense, nor GIT_WORK_TREE with an explicit "git --bare". Catch that mistake. It might make sense to move this check to "git.c" side as well, but I tried to shoot for the minimum change for now. * Some scripts, especially from the olden days, rely on traditional GIT_DIR behaviour in "git init". Namely, these are some notable patterns: (create a bare repository) - mkdir some.git && cd some.git && GIT_DIR=. git init - mkdir some.git && cd some.git && git --bare init (create a non-bare repository) - mkdir .git && GIT_DIR=.git git init - mkdir .git && GIT_DIR=`pwd`/.git git init This comes with a new test script and also passes the existing test suite, but there may be cases that are still broken with the current tip of master and this patch does not yet fix. I'd appreciate help in straightening this mess out. Signed-off-by: Junio C Hamano <gitster@pobox.com>
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)' '
t0001: use test_must_fail We've hand-rolled several "if" statements looking for failures. We can use test_must_fail here, which is shorter and more robust. Note that we modify the commands slightly (to use "git init foo" rather than "cd foo && git init") to avoid dealing with a subshell, but this should not affect the outcome. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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
Fix initialization of a bare repository Here is my attempt to fix this with a minimally intrusive patch. * As "git --bare init" cannot tell if it was called with --bare or just "GIT_DIR=. git init", I added an explicit assignment of is_bare_repository_cfg on the codepath for "git --bare". * GIT_WORK_TREE alone without GIT_DIR does not make any sense, nor GIT_WORK_TREE with an explicit "git --bare". Catch that mistake. It might make sense to move this check to "git.c" side as well, but I tried to shoot for the minimum change for now. * Some scripts, especially from the olden days, rely on traditional GIT_DIR behaviour in "git init". Namely, these are some notable patterns: (create a bare repository) - mkdir some.git && cd some.git && GIT_DIR=. git init - mkdir some.git && cd some.git && git --bare init (create a non-bare repository) - mkdir .git && GIT_DIR=.git git init - mkdir .git && GIT_DIR=`pwd`/.git git init This comes with a new test script and also passes the existing test suite, but there may be cases that are still broken with the current tip of master and this patch does not yet fix. I'd appreciate help in straightening this mess out. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-08-27 09:58:06 +02:00
'
i18n: do not overuse C_LOCALE_OUTPUT (grep) Instead of skipping the whole test, introduce test_i18ngrep wrapper that pretends a successful result under GETTEXT_POISON build. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-13 00:57:08 +02:00
test_expect_success 'reinit' '
init: show "Reinit" message even in an (existing) empty repository Earlier, git-init tested for a valid HEAD ref, but if the repository was empty, there was none. Instead, test for the existence of the file $GIT_DIR/HEAD. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-24 16:14:52 +01:00
(
mkdir again &&
cd again &&
git init >out1 2>err1 &&
git init >out2 2>err2
) &&
i18n: do not overuse C_LOCALE_OUTPUT (grep) Instead of skipping the whole test, introduce test_i18ngrep wrapper that pretends a successful result under GETTEXT_POISON build. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-13 00:57:08 +02:00
test_i18ngrep "Initialized empty" again/out1 &&
test_i18ngrep "Reinitialized existing" again/out2 &&
init: show "Reinit" message even in an (existing) empty repository Earlier, git-init tested for a valid HEAD ref, but if the repository was empty, there was none. Instead, test for the existence of the file $GIT_DIR/HEAD. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-24 16:14:52 +01:00
>again/empty &&
i18n: do not overuse C_LOCALE_OUTPUT (grep) Instead of skipping the whole test, introduce test_i18ngrep wrapper that pretends a successful result under GETTEXT_POISON build. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-13 00:57:08 +02:00
test_i18ncmp again/empty again/err1 &&
test_i18ncmp again/empty again/err2
init: show "Reinit" message even in an (existing) empty repository Earlier, git-init tested for a valid HEAD ref, but if the repository was empty, there was none. Instead, test for the existence of the file $GIT_DIR/HEAD. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-24 16:14:52 +01:00
'
init: handle empty "template" parameter If a user passes "--template=", then our template parameter is blank. Unfortunately, copy_templates() assumes it has at least one character, and does all sorts of bad things like reading from template[-1] and then proceeding to link all of '/' into the .git directory. This patch just checks for that condition in copy_templates and aborts. As a side effect, this means that --template= now has the meaning "don't copy any templates." Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-28 08:02:04 +02:00
test_expect_success 'init with --template' '
mkdir template-source &&
echo content >template-source/file &&
t0001: drop subshells just for "cd" Many tests do something like: ( mkdir foo && cd foo && git init ) You can do the same these days with "git init foo", which makes the tests shorter and simpler to read. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-21 00:23:06 +01:00
git init --template=../template-source template-custom &&
init: handle empty "template" parameter If a user passes "--template=", then our template parameter is blank. Unfortunately, copy_templates() assumes it has at least one character, and does all sorts of bad things like reading from template[-1] and then proceeding to link all of '/' into the .git directory. This patch just checks for that condition in copy_templates and aborts. As a side effect, this means that --template= now has the meaning "don't copy any templates." Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-28 08:02:04 +02:00
test_cmp template-source/file template-custom/.git/file
'
test_expect_success 'init with --template (blank)' '
t0001: drop subshells just for "cd" Many tests do something like: ( mkdir foo && cd foo && git init ) You can do the same these days with "git init foo", which makes the tests shorter and simpler to read. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-21 00:23:06 +01:00
git init template-plain &&
t0001: use test_path_is_* t0001 predates the test_path_is_* helpers, and uses "test -f" and "test -d" directly. Using the helpers provides better debugging output, and are a little more robust. As opposed to "! test -d", test_path_is_missing will actually makes sure the path does not exist at all. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-21 00:17:35 +01:00
test_path_is_file template-plain/.git/info/exclude &&
t0001: drop subshells just for "cd" Many tests do something like: ( mkdir foo && cd foo && git init ) You can do the same these days with "git init foo", which makes the tests shorter and simpler to read. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-21 00:23:06 +01:00
git init --template= template-blank &&
t0001: use test_path_is_* t0001 predates the test_path_is_* helpers, and uses "test -f" and "test -d" directly. Using the helpers provides better debugging output, and are a little more robust. As opposed to "! test -d", test_path_is_missing will actually makes sure the path does not exist at all. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-21 00:17:35 +01:00
test_path_is_missing template-blank/.git/info/exclude
init: handle empty "template" parameter If a user passes "--template=", then our template parameter is blank. Unfortunately, copy_templates() assumes it has at least one character, and does all sorts of bad things like reading from template[-1] and then proceeding to link all of '/' into the .git directory. This patch just checks for that condition in copy_templates and aborts. As a side effect, this means that --template= now has the meaning "don't copy any templates." Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-28 08:02:04 +02:00
'
t/t0001-init.sh: add test for 'init with init.templatedir set' Requires a small change to wrap-for-bin.sh in order to work. Signed-off-by: Steven Drake <sdrake@xnet.co.nz> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-26 05:00:21 +01:00
test_expect_success 'init with init.templatedir set' '
mkdir templatedir-source &&
echo Content >templatedir-source/file &&
t0001: use test_config_global We hand-set several config options using : git config -f $HOME/.gitconfig ... Instead, we can use "test_config_global". Not only is this more readable, but it cleans up for us so that subsequent tests aren't polluted by our settings. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-21 00:18:12 +01:00
test_config_global init.templatedir "${HOME}/templatedir-source" &&
t/t0001-init.sh: add test for 'init with init.templatedir set' Requires a small change to wrap-for-bin.sh in order to work. Signed-off-by: Steven Drake <sdrake@xnet.co.nz> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-26 05:00:21 +01:00
(
mkdir templatedir-set &&
cd templatedir-set &&
Introduce sane_unset and use it to ensure proper && chaining Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-10-03 22:00:14 +02:00
sane_unset GIT_TEMPLATE_DIR &&
t/t0001-init.sh: add test for 'init with init.templatedir set' Requires a small change to wrap-for-bin.sh in order to work. Signed-off-by: Steven Drake <sdrake@xnet.co.nz> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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' '
t0001: use test_config_global We hand-set several config options using : git config -f $HOME/.gitconfig ... Instead, we can use "test_config_global". Not only is this more readable, but it cleans up for us so that subsequent tests aren't polluted by our settings. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-21 00:18:12 +01:00
test_config_global core.bare false &&
test_config_global core.sharedRepository 0640 &&
t0001: drop subshells just for "cd" Many tests do something like: ( mkdir foo && cd foo && git init ) You can do the same these days with "git init foo", which makes the tests shorter and simpler to read. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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 = \
t0001-init.sh: use the $( ... ) construct for command substitution The Git CodingGuidelines prefer the $(...) construct for command substitution instead of using the backquotes `...`. The backquoted form is the traditional method for command substitution, and is supported by POSIX. However, all but the simplest uses become complicated quickly. In particular, embedded command substitutions and/or the use of double quotes require careful escaping with the backslash character. The patch was generated by: for _f in $(find . -name "*.sh") do sed -i 's@`\(.*\)`@$(\1)@g' ${_f} done and then carefully proof-read. Signed-off-by: Elia Pinto <gitter.spiros@gmail.com> Reviewed-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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' '
t0001: use test_config_global We hand-set several config options using : git config -f $HOME/.gitconfig ... Instead, we can use "test_config_global". Not only is this more readable, but it cleans up for us so that subsequent tests aren't polluted by our settings. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-21 00:18:12 +01:00
test_config_global core.sharedRepository 0666 &&
t0001: drop subshells just for "cd" Many tests do something like: ( mkdir foo && cd foo && git init ) You can do the same these days with "git init foo", which makes the tests shorter and simpler to read. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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 = \
t0001-init.sh: use the $( ... ) construct for command substitution The Git CodingGuidelines prefer the $(...) construct for command substitution instead of using the backquotes `...`. The backquoted form is the traditional method for command substitution, and is supported by POSIX. However, all but the simplest uses become complicated quickly. In particular, embedded command substitutions and/or the use of double quotes require careful escaping with the backslash character. The patch was generated by: for _f in $(find . -name "*.sh") do sed -i 's@`\(.*\)`@$(\1)@g' ${_f} done and then carefully proof-read. Signed-off-by: Elia Pinto <gitter.spiros@gmail.com> Reviewed-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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
'
init: use strbufs to store paths The init code predates strbufs, and uses PATH_MAX-sized buffers along with many manual checks on intermediate sizes (some of which make magic assumptions, such as that init will not create a path inside .git longer than 50 characters). We can simplify this greatly by using strbufs, which drops some hard-to-verify strcpy calls in favor of git_path_buf. While we're in the area, let's also convert existing calls to git_path to the safer git_path_buf (our existing calls were passed to pretty tame functions, and so were not a problem, but it's easy to be consistent and safe here). Note that we had an explicit test that "git init" rejects long template directories. This comes from 32d1776 (init: Do not segfault on big GIT_TEMPLATE_DIR environment variable, 2009-04-18). We can drop the test_must_fail here, as we now accept this and need only confirm that we don't segfault, which was the original point of the test. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-10-05 05:46:04 +02:00
test_expect_success 'init allows insanely long --template' '
git init --template=$(printf "x%09999dx" 1) test
init: Do not segfault on big GIT_TEMPLATE_DIR environment variable Signed-off-by: Frank Lichtenheld <flichtenheld@astaro.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-18 16:14:02 +02:00
'
git init: optionally allow a directory argument When starting a new repository, I see my students often say % git init newrepo and curse git. They could say % mkdir newrepo; cd newrepo; git init but allowing it as an obvious short-cut may be nicer. Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-24 23:59:28 +02:00
test_expect_success 'init creates a new directory' '
rm -fr newdir &&
t0001: drop useless subshells Many tests use subshells, but don't actually change the shell environment. They were probably cargo-culted from earlier tests which did need subshells. Drop the useless ones. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-21 00:21:25 +01:00
git init newdir &&
test_path_is_dir newdir/.git/refs
git init: optionally allow a directory argument When starting a new repository, I see my students often say % git init newrepo and curse git. They could say % mkdir newrepo; cd newrepo; git init but allowing it as an obvious short-cut may be nicer. Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-24 23:59:28 +02:00
'
test_expect_success 'init creates a new bare directory' '
rm -fr newdir &&
t0001: drop useless subshells Many tests use subshells, but don't actually change the shell environment. They were probably cargo-culted from earlier tests which did need subshells. Drop the useless ones. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-21 00:21:25 +01:00
git init --bare newdir &&
test_path_is_dir newdir/refs
git init: optionally allow a directory argument When starting a new repository, I see my students often say % git init newrepo and curse git. They could say % mkdir newrepo; cd newrepo; git init but allowing it as an obvious short-cut may be nicer. Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-24 23:59:28 +02:00
'
test_expect_success 'init recreates a directory' '
rm -fr newdir &&
t0001: drop useless subshells Many tests use subshells, but don't actually change the shell environment. They were probably cargo-culted from earlier tests which did need subshells. Drop the useless ones. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-21 00:21:25 +01:00
mkdir newdir &&
git init newdir &&
test_path_is_dir newdir/.git/refs
git init: optionally allow a directory argument When starting a new repository, I see my students often say % git init newrepo and curse git. They could say % mkdir newrepo; cd newrepo; git init but allowing it as an obvious short-cut may be nicer. Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-24 23:59:28 +02:00
'
test_expect_success 'init recreates a new bare directory' '
rm -fr newdir &&
t0001: drop useless subshells Many tests use subshells, but don't actually change the shell environment. They were probably cargo-culted from earlier tests which did need subshells. Drop the useless ones. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-21 00:21:25 +01:00
mkdir newdir &&
git init --bare newdir &&
test_path_is_dir newdir/refs
git init: optionally allow a directory argument When starting a new repository, I see my students often say % git init newrepo and curse git. They could say % mkdir newrepo; cd newrepo; git init but allowing it as an obvious short-cut may be nicer. Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-24 23:59:28 +02:00
'
test_expect_success 'init creates a new deep directory' '
t0001-init: split the existence test from the permission test The test for correct permissions after init created a deep directory must be guarded by POSIXPERM. But testing that the deep dirctory exists is good even on platforms that do not provide the POSIXPERM prerequiste. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-09 18:02:55 +02:00
rm -fr newdir &&
git init newdir/a/b/c &&
t0001: use test_path_is_* t0001 predates the test_path_is_* helpers, and uses "test -f" and "test -d" directly. Using the helpers provides better debugging output, and are a little more robust. As opposed to "! test -d", test_path_is_missing will actually makes sure the path does not exist at all. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-21 00:17:35 +01:00
test_path_is_dir newdir/a/b/c/.git/refs
t0001-init: split the existence test from the permission test The test for correct permissions after init created a deep directory must be guarded by POSIXPERM. But testing that the deep dirctory exists is good even on platforms that do not provide the POSIXPERM prerequiste. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-09 18:02:55 +02:00
'
test_expect_success POSIXPERM 'init creates a new deep directory (umask vs. shared)' '
git init: optionally allow a directory argument When starting a new repository, I see my students often say % git init newrepo and curse git. They could say % mkdir newrepo; cd newrepo; git init but allowing it as an obvious short-cut may be nicer. Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-24 23:59:28 +02:00
rm -fr newdir &&
(
# Leading directories should honor umask while
# the repository itself should follow "shared"
umask 002 &&
git init --bare --shared=0660 newdir/a/b/c &&
t0001: use test_path_is_* t0001 predates the test_path_is_* helpers, and uses "test -f" and "test -d" directly. Using the helpers provides better debugging output, and are a little more robust. As opposed to "! test -d", test_path_is_missing will actually makes sure the path does not exist at all. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-21 00:17:35 +01:00
test_path_is_dir newdir/a/b/c/refs &&
git init: optionally allow a directory argument When starting a new repository, I see my students often say % git init newrepo and curse git. They could say % mkdir newrepo; cd newrepo; git init but allowing it as an obvious short-cut may be nicer. Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-24 23:59:28 +02:00
ls -ld newdir/a newdir/a/b > lsab.out &&
t0001-init: fix a file name Without this change, grep fails because it does not find the file instead of because it does not find the text in the file. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-09 17:38:04 +02:00
! grep -v "^drwxrw[sx]r-x" lsab.out &&
git init: optionally allow a directory argument When starting a new repository, I see my students often say % git init newrepo and curse git. They could say % mkdir newrepo; cd newrepo; git init but allowing it as an obvious short-cut may be nicer. Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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 &&
t0001: drop useless subshells Many tests use subshells, but don't actually change the shell environment. They were probably cargo-culted from earlier tests which did need subshells. Drop the useless ones. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-21 00:21:25 +01:00
>newdir &&
test_must_fail git init newdir &&
test_path_is_file newdir
git init: optionally allow a directory argument When starting a new repository, I see my students often say % git init newrepo and curse git. They could say % mkdir newrepo; cd newrepo; git init but allowing it as an obvious short-cut may be nicer. Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-24 23:59:28 +02:00
'
test_expect_success 'init notices EEXIST (2)' '
rm -fr newdir &&
t0001: drop useless subshells Many tests use subshells, but don't actually change the shell environment. They were probably cargo-culted from earlier tests which did need subshells. Drop the useless ones. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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
git init: optionally allow a directory argument When starting a new repository, I see my students often say % git init newrepo and curse git. They could say % mkdir newrepo; cd newrepo; git init but allowing it as an obvious short-cut may be nicer. Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-24 23:59:28 +02:00
'
tests: A SANITY test prereq for testing if we're root Some tests depend on not being able to write to files after chmod -w. This doesn't work when running the tests as root. Change test-lib.sh to test if this works, and if so it sets a new SANITY test prerequisite. The tests that use this previously failed when run under root. There was already a test for this in t3600-rm.sh, added by Junio C Hamano in 2283645 in 2006. That check now uses the new SANITY prerequisite. Some of this was resurrected from the "Tests in Cygwin" thread in May 2009: http://thread.gmane.org/gmane.comp.version-control.git/116729/focus=118385 Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-07 00:09:09 +02:00
test_expect_success POSIXPERM,SANITY 'init notices EPERM' '
git init: optionally allow a directory argument When starting a new repository, I see my students often say % git init newrepo and curse git. They could say % mkdir newrepo; cd newrepo; git init but allowing it as an obvious short-cut may be nicer. Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-24 23:59:28 +02:00
rm -fr newdir &&
t0001: drop useless subshells Many tests use subshells, but don't actually change the shell environment. They were probably cargo-culted from earlier tests which did need subshells. Drop the useless ones. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-21 00:21:25 +01:00
mkdir newdir &&
chmod -w newdir &&
test_must_fail git init newdir/a/b
git init: optionally allow a directory argument When starting a new repository, I see my students often say % git init newrepo and curse git. They could say % mkdir newrepo; cd newrepo; git init but allowing it as an obvious short-cut may be nicer. Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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 &&
t0001: use test_path_is_* t0001 predates the test_path_is_* helpers, and uses "test -f" and "test -d" directly. Using the helpers provides better debugging output, and are a little more robust. As opposed to "! test -d", test_path_is_missing will actually makes sure the path does not exist at all. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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 &&
t0001: use test_path_is_* t0001 predates the test_path_is_* helpers, and uses "test -f" and "test -d" directly. Using the helpers provides better debugging output, and are a little more robust. As opposed to "! test -d", test_path_is_missing will actually makes sure the path does not exist at all. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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
'
init, clone: support --separate-git-dir for .git file --separate-git-dir tells git to create git dir at the specified location, instead of where it is supposed to be. A .git file that points to that location will be put in place so that it appears normal to repo discovery process. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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 &&
t0001-init.sh: use the $( ... ) construct for command substitution The Git CodingGuidelines prefer the $(...) construct for command substitution instead of using the backquotes `...`. The backquoted form is the traditional method for command substitution, and is supported by POSIX. However, all but the simplest uses become complicated quickly. In particular, embedded command substitutions and/or the use of double quotes require careful escaping with the backslash character. The patch was generated by: for _f in $(find . -name "*.sh") do sed -i 's@`\(.*\)`@$(\1)@g' ${_f} done and then carefully proof-read. Signed-off-by: Elia Pinto <gitter.spiros@gmail.com> Reviewed-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-04-28 14:57:24 +02:00
echo "gitdir: $(pwd)/realgitdir" >expected &&
init, clone: support --separate-git-dir for .git file --separate-git-dir tells git to create git dir at the specified location, instead of where it is supposed to be. A .git file that points to that location will be put in place so that it appears normal to repo discovery process. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-19 16:16:56 +01:00
test_cmp expected newdir/.git &&
t0001: use test_path_is_* t0001 predates the test_path_is_* helpers, and uses "test -f" and "test -d" directly. Using the helpers provides better debugging output, and are a little more robust. As opposed to "! test -d", test_path_is_missing will actually makes sure the path does not exist at all. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-21 00:17:35 +01:00
test_path_is_dir realgitdir/refs
init, clone: support --separate-git-dir for .git file --separate-git-dir tells git to create git dir at the specified location, instead of where it is supposed to be. A .git file that points to that location will be put in place so that it appears normal to repo discovery process. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-19 16:16:56 +01:00
'
Make setup_git_env() resolve .git file when $GIT_DIR is not specified This makes reinitializing on a .git file repository work. This is probably the only case that setup_git_env() (via set_git_dir()) is called on a .git file. Other cases in setup_git_dir_gently() and enter_repo() both cover .git file case explicitly because they need to verify the target repo is valid. Reported-by: Ximin Luo <infinity0@gmx.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-31 03:04:14 +02:00
test_expect_success 're-init on .git file' '
( cd newdir && git init )
'
init, clone: support --separate-git-dir for .git file --separate-git-dir tells git to create git dir at the specified location, instead of where it is supposed to be. A .git file that points to that location will be put in place so that it appears normal to repo discovery process. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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
) &&
t0001-init.sh: use the $( ... ) construct for command substitution The Git CodingGuidelines prefer the $(...) construct for command substitution instead of using the backquotes `...`. The backquoted form is the traditional method for command substitution, and is supported by POSIX. However, all but the simplest uses become complicated quickly. In particular, embedded command substitutions and/or the use of double quotes require careful escaping with the backslash character. The patch was generated by: for _f in $(find . -name "*.sh") do sed -i 's@`\(.*\)`@$(\1)@g' ${_f} done and then carefully proof-read. Signed-off-by: Elia Pinto <gitter.spiros@gmail.com> Reviewed-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-04-28 14:57:24 +02:00
echo "gitdir: $(pwd)/surrealgitdir" >expected &&
init, clone: support --separate-git-dir for .git file --separate-git-dir tells git to create git dir at the specified location, instead of where it is supposed to be. A .git file that points to that location will be put in place so that it appears normal to repo discovery process. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-19 16:16:56 +01:00
test_cmp expected newdir/.git &&
t0001: use test_path_is_* t0001 predates the test_path_is_* helpers, and uses "test -f" and "test -d" directly. Using the helpers provides better debugging output, and are a little more robust. As opposed to "! test -d", test_path_is_missing will actually makes sure the path does not exist at all. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-21 00:17:35 +01:00
test_path_is_dir surrealgitdir/refs &&
test_path_is_missing realgitdir/refs
init, clone: support --separate-git-dir for .git file --separate-git-dir tells git to create git dir at the specified location, instead of where it is supposed to be. A .git file that points to that location will be put in place so that it appears normal to repo discovery process. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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
) &&
t0001-init.sh: use the $( ... ) construct for command substitution The Git CodingGuidelines prefer the $(...) construct for command substitution instead of using the backquotes `...`. The backquoted form is the traditional method for command substitution, and is supported by POSIX. However, all but the simplest uses become complicated quickly. In particular, embedded command substitutions and/or the use of double quotes require careful escaping with the backslash character. The patch was generated by: for _f in $(find . -name "*.sh") do sed -i 's@`\(.*\)`@$(\1)@g' ${_f} done and then carefully proof-read. Signed-off-by: Elia Pinto <gitter.spiros@gmail.com> Reviewed-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-04-28 14:57:24 +02:00
echo "gitdir: $(pwd)/realgitdir" >expected &&
init, clone: support --separate-git-dir for .git file --separate-git-dir tells git to create git dir at the specified location, instead of where it is supposed to be. A .git file that points to that location will be put in place so that it appears normal to repo discovery process. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-19 16:16:56 +01:00
test_cmp expected newdir/.git &&
t0001: use test_path_is_* t0001 predates the test_path_is_* helpers, and uses "test -f" and "test -d" directly. Using the helpers provides better debugging output, and are a little more robust. As opposed to "! test -d", test_path_is_missing will actually makes sure the path does not exist at all. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-21 00:17:35 +01:00
test_path_is_dir realgitdir/refs
init, clone: support --separate-git-dir for .git file --separate-git-dir tells git to create git dir at the specified location, instead of where it is supposed to be. A .git file that points to that location will be put in place so that it appears normal to repo discovery process. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-19 16:16:56 +01:00
'
t0001: guard a new test with SYMLINKS prerequisite Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-12 08:30:49 +02:00
test_expect_success SYMLINKS 're-init to move gitdir symlink' '
init, clone: support --separate-git-dir for .git file --separate-git-dir tells git to create git dir at the specified location, instead of where it is supposed to be. A .git file that points to that location will be put in place so that it appears normal to repo discovery process. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-19 16:16:56 +01:00
rm -rf newdir realgitdir &&
git init newdir &&
(
cd newdir &&
mv .git here &&
ln -s here .git &&
init/clone: remove short option -L and document --separate-git-dir Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-24 18:40:32 +02:00
git init --separate-git-dir ../realgitdir
init, clone: support --separate-git-dir for .git file --separate-git-dir tells git to create git dir at the specified location, instead of where it is supposed to be. A .git file that points to that location will be put in place so that it appears normal to repo discovery process. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-19 16:16:56 +01:00
) &&
t0001-init.sh: use the $( ... ) construct for command substitution The Git CodingGuidelines prefer the $(...) construct for command substitution instead of using the backquotes `...`. The backquoted form is the traditional method for command substitution, and is supported by POSIX. However, all but the simplest uses become complicated quickly. In particular, embedded command substitutions and/or the use of double quotes require careful escaping with the backslash character. The patch was generated by: for _f in $(find . -name "*.sh") do sed -i 's@`\(.*\)`@$(\1)@g' ${_f} done and then carefully proof-read. Signed-off-by: Elia Pinto <gitter.spiros@gmail.com> Reviewed-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-04-28 14:57:24 +02:00
echo "gitdir: $(pwd)/realgitdir" >expected &&
init, clone: support --separate-git-dir for .git file --separate-git-dir tells git to create git dir at the specified location, instead of where it is supposed to be. A .git file that points to that location will be put in place so that it appears normal to repo discovery process. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-19 16:16:56 +01:00
test_cmp expected newdir/.git &&
t0001: make symlink reinit test more careful In the final test of t0001, we have a repo whose .git is a symlink to a directory "here", and we use "--separate-git-dir" to migrate that to a .git file pointing to a different directory. We check that the data is migrated to the new directory and that .git looks like a git-file. We also check that "here" is not a directory, which is slightly misleading. It should not be a directory, but neither should it be gone. It is the actual resting place of the git-file, and .git remains a symlink to it. Let's check that more explicitly, both to make our test more robust, and to make further cleanups in this area more obvious. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-21 00:17:15 +01:00
test_cmp expected newdir/here &&
t0001: use test_path_is_* t0001 predates the test_path_is_* helpers, and uses "test -f" and "test -d" directly. Using the helpers provides better debugging output, and are a little more robust. As opposed to "! test -d", test_path_is_missing will actually makes sure the path does not exist at all. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-21 00:17:35 +01:00
test_path_is_dir realgitdir/refs
init, clone: support --separate-git-dir for .git file --separate-git-dir tells git to create git dir at the specified location, instead of where it is supposed to be. A .git file that points to that location will be put in place so that it appears normal to repo discovery process. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-19 16:16:56 +01:00
'
Fix initialization of a bare repository Here is my attempt to fix this with a minimally intrusive patch. * As "git --bare init" cannot tell if it was called with --bare or just "GIT_DIR=. git init", I added an explicit assignment of is_bare_repository_cfg on the codepath for "git --bare". * GIT_WORK_TREE alone without GIT_DIR does not make any sense, nor GIT_WORK_TREE with an explicit "git --bare". Catch that mistake. It might make sense to move this check to "git.c" side as well, but I tried to shoot for the minimum change for now. * Some scripts, especially from the olden days, rely on traditional GIT_DIR behaviour in "git init". Namely, these are some notable patterns: (create a bare repository) - mkdir some.git && cd some.git && GIT_DIR=. git init - mkdir some.git && cd some.git && git --bare init (create a non-bare repository) - mkdir .git && GIT_DIR=.git git init - mkdir .git && GIT_DIR=`pwd`/.git git init This comes with a new test script and also passes the existing test suite, but there may be cases that are still broken with the current tip of master and this patch does not yet fix. I'd appreciate help in straightening this mess out. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-08-27 09:58:06 +02:00
test_done
Copy permalink