summaryrefslogtreecommitdiff
path: root/t/t0001-init.sh
AgeCommit message (Collapse)AuthorFilesLines
2016-05-11mingw: introduce the 'core.hideDotFiles' settingLibravatar Johannes Schindelin1-0/+30
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-03-04Merge branch 'nd/clear-gitenv-upon-use-of-alias'Libravatar Junio C Hamano1-11/+9
Hotfix for a test breakage made between 2.7 and 'master'. * nd/clear-gitenv-upon-use-of-alias: t0001: fix GIT_* environment variable check under --valgrind
2016-03-03t0001: fix GIT_* environment variable check under --valgrindLibravatar Johannes Sixt1-11/+9
When a test case is run without --valgrind, the wrap-for-bin.sh helper script inserts the environment variable GIT_TEXTDOMAINDIR, but when run with --valgrind, the variable is missing. A recently introduced test case expects the presence of the variable, though, and fails under --valgrind. Rewrite the test case to strip conditially defined environment variables from both expected and actual output. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-20Merge branch 'nd/clear-gitenv-upon-use-of-alias'Libravatar Junio C Hamano1-0/+17
d95138e6 (setup: set env $GIT_WORK_TREE when work tree is set, like $GIT_DIR, 2015-06-26) attempted to work around a glitch in alias handling by overwriting GIT_WORK_TREE environment variable to affect subprocesses when set_git_work_tree() gets called, which resulted in a rather unpleasant regression to "clone" and "init". Try to address the same issue by always restoring the environment and respawning the real underlying command when handling alias. * nd/clear-gitenv-upon-use-of-alias: run-command: don't warn on SIGPIPE deaths git.c: make sure we do not leak GIT_* to alias scripts setup.c: re-fix d95138e (setup: set env $GIT_WORK_TREE when .. git.c: make it clear save_env() is for alias handling only
2015-12-22git.c: make sure we do not leak GIT_* to alias scriptsLibravatar Nguyễn Thái Ngọc Duy1-0/+17
The unfortunate commit d95138e (setup: set env $GIT_WORK_TREE when work tree is set, like $GIT_DIR - 2015-06-26) exposes another problem, besides git-clone that's described in the previous commit. If GIT_WORK_TREE (or even GIT_DIR) is exported to an alias script, it may mislead git commands in the script where the repo is. Granted, most scripts work on the repo where the alias is summoned from. But nowhere do we forbid the script to visit another repository. The revert of d95138e in the previous commit is sufficient as a fix. However, to protect us from accidentally leaking GIT_* environment variables again, we restore certain sensitive env before calling the external script. GIT_PREFIX is let through because there's another setup side effect that we simply accepted so far: current working directory is moved. Maybe in future we can introduce a new alias format that guarantees no cwd move, then we can unexport GIT_PREFIX. Reported-by: Gabriel Ganne <gabriel.ganne@gmail.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-10-05init: use strbufs to store pathsLibravatar Jeff King1-2/+2
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>
2014-12-05Merge branch 'mh/config-flip-xbit-back-after-checking'Libravatar Junio C Hamano1-0/+7
* mh/config-flip-xbit-back-after-checking: create_default_files(): don't set u+x bit on $GIT_DIR/config
2014-11-18create_default_files(): don't set u+x bit on $GIT_DIR/configLibravatar Michael Haggerty1-0/+7
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-06-25Merge branch 'nd/init-restore-env'Libravatar Junio C Hamano1-2/+2
Some subcommands do not want to be aliased because of the side effects that happens while the definitions of the aliases are looked up from configuration system. * nd/init-restore-env: git potty: restore environments after alias expansion
2014-06-10git potty: restore environments after alias expansionLibravatar Nguyễn Thái Ngọc Duy1-2/+2
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-03Merge branch 'ep/shell-command-substitution'Libravatar Junio C Hamano1-6/+6
Adjust shell scripts to use $(cmd) instead of `cmd`. * ep/shell-command-substitution: (41 commits) t5000-tar-tree.sh: use the $( ... ) construct for command substitution t4204-patch-id.sh: use the $( ... ) construct for command substitution t4119-apply-config.sh: use the $( ... ) construct for command substitution t4116-apply-reverse.sh: use the $( ... ) construct for command substitution t4057-diff-combined-paths.sh: use the $( ... ) construct for command substitution t4038-diff-combined.sh: use the $( ... ) construct for command substitution t4036-format-patch-signer-mime.sh: use the $( ... ) construct for command substitution t4014-format-patch.sh: use the $( ... ) construct for command substitution t4013-diff-various.sh: use the $( ... ) construct for command substitution t4012-diff-binary.sh: use the $( ... ) construct for command substitution t4010-diff-pathspec.sh: use the $( ... ) construct for command substitution t4006-diff-mode.sh: use the $( ... ) construct for command substitution t3910-mac-os-precompose.sh: use the $( ... ) construct for command substitution t3905-stash-include-untracked.sh: use the $( ... ) construct for command substitution t1050-large.sh: use the $( ... ) construct for command substitution t1020-subdirectory.sh: use the $( ... ) construct for command substitution t1004-read-tree-m-u-wf.sh: use the $( ... ) construct for command substitution t1003-read-tree-prefix.sh: use the $( ... ) construct for command substitution t1002-read-tree-m-u-2way.sh: use the $( ... ) construct for command substitution t1001-read-tree-m-2way.sh: use the $( ... ) construct for command substitution ...
2014-04-29t0001-init.sh: use the $( ... ) construct for command substitutionLibravatar Elia Pinto1-6/+6
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-03-21t0001: drop subshells just for "cd"Libravatar Jeff King1-47/+9
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-21t0001: drop useless subshellsLibravatar Jeff King1-39/+22
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-21t0001: use test_must_failLibravatar Jeff King1-27/+11
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-21t0001: use test_config_globalLibravatar Jeff King1-7/+4
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-21t0001: use test_path_is_*Libravatar Jeff King1-18/+18
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-21t0001: make symlink reinit test more carefulLibravatar Jeff King1-2/+2
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-21t: stop using GIT_CONFIG to cross repo boundariesLibravatar Jeff King1-2/+2
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-21t: drop useless sane_unset GIT_* callsLibravatar Jeff King1-15/+0
Several test scripts manually unset GIT_CONFIG and other GIT_* variables. These are generally taken care of for us by test-lib.sh already. Unsetting these is not only useless, but can be confusing to a reader, who may wonder why some tests in a script unset them and others do not (t0001 is particularly guilty of this inconsistency, probably because many of its tests predate the test-lib.sh environment-cleansing). Note that we cannot always get rid of such unsetting. For example, t9130 can drop the GIT_CONFIG unset, but not the GIT_DIR one, because lib-git-svn.sh sets the latter. And in t1000, we unset GIT_TEMPLATE_DIR, which is explicitly initialized by test-lib.sh. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-03Make setup_git_env() resolve .git file when $GIT_DIR is not specifiedLibravatar Nguyễn Thái Ngọc Duy1-0/+4
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>
2011-05-25Merge branch 'maint'Libravatar Junio C Hamano1-1/+1
* maint: init/clone: remove short option -L and document --separate-git-dir
2011-05-25init/clone: remove short option -L and document --separate-git-dirLibravatar Nguyen Thai Ngoc Duy1-1/+1
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-02Merge branch 'ab/i18n-fixup'Libravatar Junio C Hamano1-5/+5
* ab/i18n-fixup: (24 commits) i18n: use test_i18n{cmp,grep} in t7600, t7607, t7611 and t7811 i18n: use test_i18n{grep,cmp} in t7508 i18n: use test_i18ngrep in t7506 i18n: use test_i18ngrep and test_i18ncmp in t7502 i18n: use test_i18ngrep in t7501 i18n: use test_i18ncmp in t7500 i18n: use test_i18ngrep in t7201 i18n: use test_i18ncmp and test_i18ngrep in t7102 and t7110 i18n: use test_i18ncmp and test_i18ngrep in t5541, t6040, t6120, t7004, t7012 and t7060 i18n: use test_i18ncmp and test_i18ngrep in t3700, t4001 and t4014 i18n: use test_i18ncmp and test_i18ngrep in t3203, t3501 and t3507 i18n: use test_i18ngrep in t2020, t2204, t3030, and t3200 i18n: use test_i18ngrep in lib-httpd and t2019 i18n: do not overuse C_LOCALE_OUTPUT (grep) i18n: use test_i18ncmp in t1200 and t2200 i18n: .git file is not a human readable message (t5601) i18n: do not overuse C_LOCALE_OUTPUT i18n: mark init-db messages for translation i18n: mark checkout plural warning for translation i18n: mark checkout --detach messages for translation ...
2011-04-13i18n: do not overuse C_LOCALE_OUTPUT (grep)Libravatar Junio C Hamano1-5/+5
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-12Merge branch 'nd/init-gitdir'Libravatar Junio C Hamano1-1/+1
* nd/init-gitdir: t0001: guard a new test with SYMLINKS prerequisite
2011-04-11t0001: guard a new test with SYMLINKS prerequisiteLibravatar Johannes Sixt1-1/+1
Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-01Merge branch 'nd/init-gitdir'Libravatar Junio C Hamano1-0/+46
* nd/init-gitdir: init, clone: support --separate-git-dir for .git file git-init.txt: move description section up Conflicts: builtin/clone.c
2011-04-01Merge branch 'ab/i18n-st'Libravatar Junio C Hamano1-1/+1
* ab/i18n-st: (69 commits) i18n: git-shortlog basic messages i18n: git-revert split up "could not revert/apply" message i18n: git-revert literal "me" messages i18n: git-revert "Your local changes" message i18n: git-revert basic messages i18n: git-notes GIT_NOTES_REWRITE_MODE error message i18n: git-notes basic commands i18n: git-gc "Auto packing the repository" message i18n: git-gc basic messages i18n: git-describe basic messages i18n: git-clean clean.requireForce messages i18n: git-clean basic messages i18n: git-bundle basic messages i18n: git-archive basic messages i18n: git-status "renamed: " message i18n: git-status "Initial commit" message i18n: git-status "Changes to be committed" message i18n: git-status shortstatus messages i18n: git-status "nothing to commit" messages i18n: git-status basic messages ... Conflicts: builtin/branch.c builtin/checkout.c builtin/clone.c builtin/commit.c builtin/grep.c builtin/merge.c builtin/push.c builtin/revert.c t/t3507-cherry-pick-conflict.sh t/t7607-merge-overwrite.sh
2011-03-19init, clone: support --separate-git-dir for .git fileLibravatar Nguyễn Thái Ngọc Duy1-0/+46
--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-15config: drop support for GIT_CONFIG_NOGLOBALLibravatar Jonathan Nieder1-4/+1
Now that test-lib sets $HOME to protect against pollution from user settings, GIT_CONFIG_NOGLOBAL is not needed for use by the test suite any more. And as luck would have it, a quick code search reveals no other users in the wild. This patch does not affect GIT_CONFIG_NOSYSTEM, which is still needed. Helped-by: Jeff King <peff@peff.net> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-09i18n: git-init "Initialized [...] repository" messageLibravatar Ævar Arnfjörð Bjarmason1-1/+1
These messages could benefit from splitting up. An earlier version of this patch began like this: const char *reinit_shared = _("Reinitialized existing shared Git repository in %s\n"); const char *init_shared = _("Initialized empty shared Git repository in %s\n"); const char *reinit_noshared = _("Reinitialized existing Git repository in %s\n"); const char *init_noshared = _("Initialized empty Git repository in %s\n"); But in the first round of gettextization I'm aiming to keep code changes to a minimum for ease of review. So just add a comment explaining to translators how the sprintf format gets used so they can cope for now if the language's grammar allows. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-01-06t0001,t1510,t3301: use sane_unset which always returns with status 0Libravatar Brandon Casey1-4/+4
On some shells (like /usr/xpg4/bin/sh on Solaris), unset will exit non-zero when passed the name of a variable that has not been set. Use sane_unset instead so that the return value of unset can be ignored while the && linkage of the test script can be preserved. Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-12-28Merge branch 'nd/setup'Libravatar Junio C Hamano1-0/+56
* nd/setup: (47 commits) setup_work_tree: adjust relative $GIT_WORK_TREE after moving cwd git.txt: correct where --work-tree path is relative to Revert "Documentation: always respect core.worktree if set" t0001: test git init when run via an alias Remove all logic from get_git_work_tree() setup: rework setup_explicit_git_dir() setup: clean up setup_discovered_git_dir() t1020-subdirectory: test alias expansion in a subdirectory setup: clean up setup_bare_git_dir() setup: limit get_git_work_tree()'s to explicit setup case only Use git_config_early() instead of git_config() during repo setup Add git_config_early() git-rev-parse.txt: clarify --git-dir t1510: setup case #31 t1510: setup case #30 t1510: setup case #29 t1510: setup case #28 t1510: setup case #27 t1510: setup case #26 t1510: setup case #25 ...
2010-12-22t0001: test git init when run via an aliasLibravatar Jonathan Nieder1-0/+56
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-10-06Introduce sane_unset and use it to ensure proper && chainingLibravatar Elijah Newren1-14/+14
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-08-31tests: factor HOME=$(pwd) in test-lib.shLibravatar Matthieu Moy1-6/+0
The same pattern is used in many tests, and makes it easy for new ones to rely on $HOME being a trashable, clean, directory. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-18tests: A SANITY test prereq for testing if we're rootLibravatar Ævar Arnfjörð Bjarmason1-1/+1
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-05-10handle "git --bare init <dir>" properlyLibravatar Jeff King1-0/+14
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-02-25t/t0001-init.sh: add test for 'init with init.templatedir set'Libravatar Steven Drake1-0/+19
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>
2009-08-09t0001-init: split the existence test from the permission testLibravatar Johannes Sixt1-0/+6
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-09t0001-init: fix a file nameLibravatar Johannes Sixt1-1/+1
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-07-25git init: optionally allow a directory argumentLibravatar Nanako Shiraishi1-0/+77
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-04-18init: Do not segfault on big GIT_TEMPLATE_DIR environment variableLibravatar Frank Lichtenheld1-0/+9
Signed-off-by: Frank Lichtenheld <flichtenheld@astaro.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-10-08git init: --bare/--shared overrides system/global configLibravatar Deskin Miller1-0/+32
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-07-27init: handle empty "template" parameterLibravatar Jeff King1-0/+26
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-11t0001-init.sh: change confusing directory nameLibravatar Miklos Vajna1-3/+3
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-05-28git-init: accept --bare optionLibravatar Luciano Rocha1-0/+11
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-03-25init: show "Reinit" message even in an (existing) empty repositoryLibravatar Johannes Schindelin1-0/+17
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>
2007-12-04Do not rely on the exit status of "unset" for unset variablesLibravatar H.Merijn Brand1-8/+8
POSIX says that exit status "0" means that "unset" successfully unset the variable. However, it is kind of ambiguous if an environment variable which was not set could be successfully unset. At least the default shell on HP-UX insists on reporting an error in such a case, so just ignore the exit status of "unset". [Dscho: extended the patch to git-submodule.sh, as Junio realized that this is the only other place where we check the exit status of "unset".] Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>