git/t/t0001-init.sh, branch v2.25.3

Merge branch 'jh/msvc'

2019-07-09T22:25:45Z

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

Merge branch 'js/t0001-case-insensitive'

2019-07-09T22:25:44Z

Test update. * js/t0001-case-insensitive: t0001: fix on case-insensitive filesystems

t0001: fix on case-insensitive filesystems

2019-06-24T18:55:54Z

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 Signed-off-by: Junio C Hamano

t0001 (mingw): do not expect a specific order of stdout/stderr

2019-06-20T21:03:05Z

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 Signed-off-by: Junio C Hamano

Merge branch 'nd/init-relative-template-fix'

2019-06-13T20:18:46Z

A relative pathname given to "git init --template= " 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

trace2: rename environment variables to GIT_TRACE2*

2019-05-28T17:20:34Z

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 Signed-off-by: Junio C Hamano

init: make --template path relative to $CWD

2019-05-13T06:13:24Z

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 Signed-off-by: Junio C Hamano

mingw: respect core.hidedotfiles = false in git-init again

2019-03-12T07:30:26Z

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 Signed-off-by: Junio C Hamano

trace2: create new combined trace facility

2019-02-22T23:27:59Z

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 Signed-off-by: Junio C Hamano

tests: send "bug in the test script" errors to the script's stderr

2018-11-20T03:16:35Z

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 Signed-off-by: Junio C Hamano