summaryrefslogtreecommitdiff
path: root/t/t0001-init.sh
AgeCommit message (Collapse)AuthorFilesLines
2019-07-09Merge branch 'jh/msvc'Libravatar Junio C Hamano1-2/+2
Support to build with MSVC has been updated. * jh/msvc: msvc: ignore .dll and incremental compile output msvc: avoid debug assertion windows in Debug Mode msvc: do not pretend to support all signals msvc: add pragmas for common warnings msvc: add a compile-time flag to allow detailed heap debugging msvc: support building Git using MS Visual C++ msvc: update Makefile to allow for spaces in the compiler path msvc: fix detect_msys_tty() msvc: define ftello() msvc: do not re-declare the timespec struct msvc: mark a variable as non-const msvc: define O_ACCMODE msvc: include sigset_t definition msvc: fix dependencies of compat/msvc.c mingw: replace mingw_startup() hack obstack: fix compiler warning cache-tree/blame: avoid reusing the DEBUG constant t0001 (mingw): do not expect a specific order of stdout/stderr Mark .bat files as requiring CR/LF endings mingw: fix a typo in the msysGit-specific section
2019-07-09Merge branch 'js/t0001-case-insensitive'Libravatar Junio C Hamano1-14/+8
Test update. * js/t0001-case-insensitive: t0001: fix on case-insensitive filesystems
2019-06-24t0001: fix on case-insensitive filesystemsLibravatar Johannes Schindelin1-14/+8
On a case-insensitive filesystem, such as HFS+ or NTFS, it is possible that the idea Bash has of the current directory differs in case from what Git thinks it is. That's totally okay, though, and we should not expect otherwise. On Windows, for example, when you call cd C:\GIT-SDK-64 in a PowerShell and there exists a directory called `C:\git-sdk-64`, the current directory will be reported in all upper-case. Even in a Bash that you might call from that PowerShell. Git, however, will have normalized this via `GetFinalPathByHandle()`, and the expectation in t0001 that the recorded gitdir will match what `pwd` says will be violated. Let's address this by comparing these paths in a case-insensitive manner when `core.ignoreCase` is `true`. Reported by Jameson Miller. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-20t0001 (mingw): do not expect a specific order of stdout/stderrLibravatar Johannes Schindelin1-2/+2
When redirecting stdout/stderr to the same file, we cannot guarantee that stdout will come first. In fact, in this test case, it seems that an MSVC build always prints stderr first. In any case, this test case does not want to verify the *order* but the *presence* of both outputs, so let's test exactly that. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-13Merge branch 'nd/init-relative-template-fix'Libravatar Junio C Hamano1-1/+1
A relative pathname given to "git init --template=<path> <repo>" ought to be relative to the directory "git init" gets invoked in, but it instead was made relative to the repository, which has been corrected. * nd/init-relative-template-fix: init: make --template path relative to $CWD
2019-05-28trace2: rename environment variables to GIT_TRACE2*Libravatar SZEDER Gábor1-1/+1
For an environment variable that is supposed to be set by users, the GIT_TR2* env vars are just too unclear, inconsistent, and ugly. Most of the established GIT_* environment variables don't use abbreviations, and in case of the few that do (GIT_DIR, GIT_COMMON_DIR, GIT_DIFF_OPTS) it's quite obvious what the abbreviations (DIR and OPTS) stand for. But what does TR stand for? Track, traditional, trailer, transaction, transfer, transformation, transition, translation, transplant, transport, traversal, tree, trigger, truncate, trust, or ...?! The trace2 facility, as the '2' suffix in its name suggests, is supposed to eventually supercede Git's original trace facility. It's reasonable to expect that the corresponding environment variables follow suit, and after the original GIT_TRACE variables they are called GIT_TRACE2; there is no such thing is 'GIT_TR'. All trace2-specific config variables are, very sensibly, in the 'trace2' section, not in 'tr2'. OTOH, we don't gain anything at all by omitting the last three characters of "trace" from the names of these environment variables. So let's rename all GIT_TR2* environment variables to GIT_TRACE2*, before they make their way into a stable release. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-13init: make --template path relative to $CWDLibravatar Nguyễn Thái Ngọc Duy1-1/+1
During git-init we chdir() to the target directory, but --template is not adjusted. So it's relative to the target directory instead of current directory. It would be ok if it's documented, but --template in git-init.txt mentions nothing about this behavior. Change it to be relative to $CWD, which is much more intuitive. The changes in the test suite show that this relative-to-target behavior is actually used. I just hope that it's only used in the test suite and it's safe to change. Otherwise, the other option is just document it (i.e. relative to target dir) and move on. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-03-12mingw: respect core.hidedotfiles = false in git-init againLibravatar Johannes Schindelin1-0/+11
This is a brown paper bag. When adding the tests, we actually failed to verify that the config variable is heeded in git-init at all. And when changing the original patch that marked the .git/ directory as hidden after reading the config, it was lost on this developer that the new code would use the hide_dotfiles variable before the config was read. The fix is obvious: read the (limited, pre-init) config *before* creating the .git/ directory. Please note that we cannot remove the identical-looking `git_config()` call from `create_default_files()`: we create the `.git/` directory between those calls. If we removed it, and if the parent directory is in a Git worktree, and if that worktree's `.git/config` contained any `init.templatedir` setting, we would all of a sudden pick that up. This fixes https://github.com/git-for-windows/git/issues/789 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-22trace2: create new combined trace facilityLibravatar Jeff Hostetler1-0/+1
Create a new unified tracing facility for git. The eventual intent is to replace the current trace_printf* and trace_performance* routines with a unified set of git_trace2* routines. In addition to the usual printf-style API, trace2 provides higer-level event verbs with fixed-fields allowing structured data to be written. This makes post-processing and analysis easier for external tools. Trace2 defines 3 output targets. These are set using the environment variables "GIT_TR2", "GIT_TR2_PERF", and "GIT_TR2_EVENT". These may be set to "1" or to an absolute pathname (just like the current GIT_TRACE). * GIT_TR2 is intended to be a replacement for GIT_TRACE and logs command summary data. * GIT_TR2_PERF is intended as a replacement for GIT_TRACE_PERFORMANCE. It extends the output with columns for the command process, thread, repo, absolute and relative elapsed times. It reports events for child process start/stop, thread start/stop, and per-thread function nesting. * GIT_TR2_EVENT is a new structured format. It writes event data as a series of JSON records. Calls to trace2 functions log to any of the 3 output targets enabled without the need to call different trace_printf* or trace_performance* routines. Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-20tests: send "bug in the test script" errors to the script's stderrLibravatar SZEDER Gábor1-2/+2
Some of the functions in our test library check that they were invoked properly with conditions like this: test "$#" = 2 || error "bug in the test script: not 2 parameters to test-expect-success" If this particular condition is triggered, then 'error' will abort the whole test script with a bold red error message [1] right away. However, under certain circumstances the test script will be aborted completely silently, namely if: - a similar condition in a test helper function like 'test_line_count' is triggered, - which is invoked from the test script's "main" shell [2], - and the test script is run manually (i.e. './t1234-foo.sh' as opposed to 'make t1234-foo.sh' or 'make test') [3] - and without the '--verbose' option, because the error message is printed from within 'test_eval_', where standard output is redirected either to /dev/null or to a log file. The only indication that something is wrong is that not all tests in the script are executed and at the end of the test script's output there is no "# passed all N tests" message, which are subtle and can easily go unnoticed, as I had to experience myself. Send these "bug in the test script" error messages directly to the test scripts standard error and thus to the terminal, so those bugs will be much harder to overlook. Instead of updating all ~20 such 'error' calls with a redirection, let's add a BUG() function to 'test-lib.sh', wrapping an 'error' call with the proper redirection and also including the common prefix of those error messages, and convert all those call sites [4] to use this new BUG() function instead. [1] That particular error message from 'test_expect_success' is printed in color only when running with or without '--verbose'; with '--tee' or '--verbose-log' the error is printed without color, but it is printed to the terminal nonetheless. [2] If such a condition is triggered in a subshell of a test, then 'error' won't be able to abort the whole test script, but only the subshell, which in turn causes the test to fail in the usual way, indicating loudly and clearly that something is wrong. [3] Well, 'error' aborts the test script the same way when run manually or by 'make' or 'prove', but both 'make' and 'prove' pay attention to the test script's exit status, and even a silently aborted test script would then trigger those tools' usual noticable error messages. [4] Strictly speaking, not all those 'error' calls need that redirection to send their output to the terminal, see e.g. 'test_expect_success' in the opening example, but I think it's better to be consistent. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-27Merge branch 'sg/test-must-be-empty'Libravatar Junio C Hamano1-3/+2
Test fixes. * sg/test-must-be-empty: tests: use 'test_must_be_empty' instead of 'test_cmp <empty> <out>' tests: use 'test_must_be_empty' instead of 'test_cmp /dev/null <out>' tests: use 'test_must_be_empty' instead of 'test ! -s' tests: use 'test_must_be_empty' instead of '! test -s'
2018-08-21tests: use 'test_must_be_empty' instead of 'test_cmp <empty> <out>'Libravatar SZEDER Gábor1-3/+2
Using 'test_must_be_empty' is shorter and more idiomatic than >empty && test_cmp empty out as it saves the creation of an empty file. Furthermore, sometimes the expected empty file doesn't have such a descriptive name like 'empty', and its creation is far away from the place where it's finally used for comparison (e.g. in 't7600-merge.sh', where two expected empty files are created in the 'setup' test, but are used only about 500 lines later). These cases were found by instrumenting 'test_cmp' to error out the test script when it's used to compare empty files, and then converted manually. Note that even after this patch there still remain a lot of cases where we use 'test_cmp' to check empty files: - Sometimes the expected output is not hard-coded in the test, but 'test_cmp' is used to ensure that two similar git commands produce the same output, and that output happens to be empty, e.g. the test 'submodule update --merge - ignores --merge for new submodules' in 't7406-submodule-update.sh'. - Repetitive common tasks, including preparing the expected results and running 'test_cmp', are often extracted into a helper function, and some of this helper's callsites expect no output. - For the same reason as above, the whole 'test_expect_success' block is within a helper function, e.g. in 't3070-wildmatch.sh'. - Or 'test_cmp' is invoked in a loop, e.g. the test 'cvs update (-p)' in 't9400-git-cvsserver-server.sh'. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-03t: use sane_unset() rather than 'unset' with broken &&-chainLibravatar Eric Sunshine1-2/+2
These tests intentionally break the &&-chain after using 'unset' since they don't know if 'unset' will succeed or fail and don't want a local 'unset' failure to fail the test overall. We can do better by using sane_unset(), which can be linked into the &&-chain as usual. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-15tests: clean after SANITY testsLibravatar Junio C Hamano1-0/+1
Some of our tests try to make sure Git behaves sensibly in a read-only directory, by dropping 'w' permission bit before doing a test and then restoring it after it is done. The latter is needed for the test framework to clean after itself without leaving a leftover directory that cannot be removed. Ancient parts of tests however arrange the above with chmod a-w . && ... do the test ... status=$? chmod 775 . (exit $status) which obviously would not work if the test somehow dies before it has the chance to do "chmod 775". Rewrite them by following a more robust pattern recently written tests use, which is test_when_finished "chmod 775 ." && chmod a-w . && ... do the test ... Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-02mingw: optionally redirect stderr/stdout via the same handleLibravatar Johannes Schindelin1-1/+7
The "2>&1" notation in Powershell and in Unix shells implies that stderr is redirected to the same handle into which stdout is already written. Let's use this special value to allow the same trick with GIT_REDIRECT_STDERR and GIT_REDIRECT_STDOUT: if the former's value is `2>&1`, then stderr will simply be written to the same handle as stdout. The functionality was suggested by Jeff Hostetler. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-02mingw: add experimental feature to redirect standard handlesLibravatar Johannes Schindelin1-0/+6
Particularly when calling Git from applications, such as Visual Studio's Team Explorer, it is important that stdin/stdout/stderr are closed properly. However, when spawning processes on Windows, those handles must be marked as inheritable if we want to use them, but that flag is a global flag and may very well be used by other spawned processes which then do not know to close those handles. Let's introduce a set of environment variables (GIT_REDIRECT_STDIN and friends) that specify paths to files, or even better, named pipes (which are similar to Unix sockets) and that are used by the spawned Git process. This helps work around above-mentioned issue: those named pipes will be opened in a non-inheritable way upon startup, and no handles are passed around (and therefore no inherited handles need to be closed by any spawned child). This feature shipped with Git for Windows (marked as experimental) since v2.11.0(2), so it has seen some serious testing in the meantime. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-07t0001: skip test with restrictive permissions if getpwd(3) respects themLibravatar René Scharfe1-2/+28
The sub-test "init in long base path" in t0001 checks the ability to handle long base paths with restrictive permissions (--x). On OpenBSD getcwd(3) fails in that case even for short paths. Check the two aspects separately by trying to use a long base path both with and without execute-only permissions. Only attempt the former if we know that getcwd(3) doesn't care. Original-patch-by: David Coppa <dcoppa@openbsd.org> Reported-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-26strbuf: support long paths w/o read rights in strbuf_getcwd() on FreeBSDLibravatar René Scharfe1-0/+14
FreeBSD implements getcwd(3) as a syscall, but falls back to a version based on readdir(3) if it fails for some reason. The latter requires permissions to read and execute path components, while the former does not. That means that if our buffer is too small and we're missing rights we could get EACCES, but we may succeed with a bigger buffer. Keep retrying if getcwd(3) indicates lack of permissions until our buffer can fit PATH_MAX bytes, as that's the maximum supported by the syscall on FreeBSD anyway. This way we do what we can to be able to benefit from the syscall, but we also won't loop forever if there is a real permission issue. This fixes a regression introduced with 7333ed17 (setup: convert setup_git_directory_gently_1 et al. to strbuf, 2014-07-28) for paths longer than 127 bytes with components that miss read or execute permissions (e.g. 0711 on /home for privacy reasons); we used a fixed PATH_MAX-sized buffer before. Reported-by: Zenobiusz Kunegunda <zenobiusz.kunegunda@interia.pl> Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-02Merge branch 'mm/reset-facl-before-umask-test'Libravatar Junio C Hamano1-0/+3
Test tweaks for those who have default ACL in their git source tree that interfere with the umask test. * mm/reset-facl-before-umask-test: t0001: don't let a default ACL interfere with the umask test
2017-01-30t0001: don't let a default ACL interfere with the umask testLibravatar Matt McCutchen1-0/+3
The "init creates a new deep directory (umask vs. shared)" test expects the permissions of newly created files to be based on the umask, which fails if a default ACL is inherited from the working tree for git. So attempt to remove a default ACL if there is one. Same idea as 8ed0a740dd42bd0724aebed6e3b07c4ea2a2d5e8. (I guess I'm the only one who ever runs the test suite with a default ACL set.) Signed-off-by: Matt McCutchen <matt@mattmccutchen.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-25init: do not set unnecessary core.worktreeLibravatar Nguyễn Thái Ngọc Duy1-0/+2
The function needs_work_tree_config() that is called from create_default_files() is supposed to be fed the path to ".git" that looks as if it is at the top of the working tree, and decide if that location matches the actual worktree being used. This comparison allows "git init" to decide if core.worktree needs to be recorded in the working tree. In the current code, however, we feed the return value from get_git_dir(), which can be totally different from what the function expects when "gitdir" file is involved. Instead of giving the path to the ".git" at the top of the working tree, we end up feeding the actual path that the file points at. This original location of ".git" however is only known to init_db(). Make init_db() save it and have it passed to create_default_files() as a new parameter, which passes the correct location down to needs_work_tree_config() to fix this. Noticed-by: Max Nordlund <max.nordlund@sqore.com> Helped-by: Michael J Gruber <git@drmicha.warpmail.net> Helped-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>
2016-09-25init: correct re-initialization from a linked worktreeLibravatar Nguyễn Thái Ngọc Duy1-0/+15
When 'git init' is called from a linked worktree, we treat '.git' dir (which is $GIT_COMMON_DIR/worktrees/something) as the main '.git' (i.e. $GIT_COMMON_DIR) and populate the whole repository skeleton in there. It does not harm anything (*) but it is still wrong. Since 'git init' calls set_git_dir() at preparation time, which indirectly calls get_common_dir() and correctly detects multiple worktree setup, all git_path_buf() calls in create_default_files() will return correct paths in both single and multiple worktree setups. The only thing left is copy_templates(), which targets $GIT_DIR, not $GIT_COMMON_DIR. Fix that with get_git_common_dir(). This function will return $GIT_DIR in single-worktree setup, so we don't have to make a special case for multiple-worktree here. (*) It does in fact, thanks to another bug. More on that later. Noticed-by: Max Nordlund <max.nordlund@sqore.com> Helped-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-13config: only read .git/config from configured reposLibravatar Jeff King1-0/+9
When git_config() runs, it looks in the system, user-wide, and repo-level config files. It gets the latter by calling git_pathdup(), which in turn calls get_git_dir(). If we haven't set up the git repository yet, this may simply return ".git", and we will look at ".git/config". This seems like it would be helpful (presumably we haven't set up the repository yet, so it tries to find it), but it turns out to be a bad idea for a few reasons: - it's not sufficient, and therefore hides bugs in a confusing way. Config will be respected if commands are run from the top-level of the working tree, but not from a subdirectory. - it's not always true that we haven't set up the repository _yet_; we may not want to do it at all. For instance, if you run "git init /some/path" from inside another repository, it should not load config from the existing repository. - there might be a path ".git/config", but it is not the actual repository we would find via setup_git_directory(). This may happen, e.g., if you are storing a git repository inside another git repository, but have munged one of the files in such a way that the inner repository is not valid (e.g., by removing HEAD). We have at least two bugs of the second type in git-init, introduced by ae5f677 (lazily load core.sharedrepository, 2016-03-11). It causes init to use git_configset(), which loads all of the config, including values from the current repo (if any). This shows up in two ways: 1. If we happen to be in an existing repository directory, we'll read and respect core.sharedrepository from it, even though it should have no bearing on the new repository. A new test in t1301 covers this. 2. Similarly, if we're in an existing repo that sets core.logallrefupdates, that will cause init to fail to set it in a newly created repository (because it thinks that the user's templates already did so). A new test in t0001 covers this. We also need to adjust an existing test in t1302, which gives another example of why this patch is an improvement. That test creates an embedded repository with a bogus core.repositoryformatversion of "99". It wants to make sure that we actually stop at the bogus repo rather than continuing upward to find the outer repo. So it checks that "git config core.repositoryformatversion" returns 99. But that only works because we blindly read ".git/config", even though we _know_ we're in a repository whose vintage we do not understand. After this patch, we avoid reading config from the unknown vintage repository at all, which is a safer choice. But we need to tweak the test, since core.repositoryformatversion will not return 99; it will claim that it could not find the variable at all. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-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>