summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
2016-09-29Merge branch 'jk/rebase-i-drop-ident-check' into maintLibravatar Junio C Hamano1-0/+47
Even when "git pull --rebase=preserve" (and the underlying "git rebase --preserve") can complete without creating any new commit (i.e. fast-forwards), it still insisted on having a usable ident information (read: user.email is set correctly), which was less than nice. As the underlying commands used inside "git rebase" would fail with a more meaningful error message and advice text when the bogus ident matters, this extra check was removed. * jk/rebase-i-drop-ident-check: rebase-interactive: drop early check for valid ident
2016-09-29Merge branch 'jt/format-patch-base-info-above-sig' into maintLibravatar Junio C Hamano1-6/+27
"git format-patch --base=..." feature that was recently added showed the base commit information after "-- " e-mail signature line, which turned out to be inconvenient. The base information has been moved above the signature line. * jt/format-patch-base-info-above-sig: format-patch: show base info before email signature
2016-09-29Merge branch 'ks/perf-build-with-autoconf' into maintLibravatar Junio C Hamano1-1/+7
Performance tests done via "t/perf" did not use the same set of build configuration if the user relied on autoconf generated configuration. * ks/perf-build-with-autoconf: t/perf/run: copy config.mak.autogen & friends to build area
2016-09-29Merge branch 'rs/xdiff-merge-overlapping-hunks-for-W-context' into maintLibravatar Junio C Hamano1-0/+25
"git diff -W" output needs to extend the context backward to include the header line of the current function and also forward to include the body of the entire current function up to the header line of the next one. This process may have to merge to adjacent hunks, but the code forgot to do so in some cases. * rs/xdiff-merge-overlapping-hunks-for-W-context: xdiff: fix merging of hunks with -W context and -u context
2016-09-29Merge branch 'jk/fix-remote-curl-url-wo-proto' into maintLibravatar Junio C Hamano1-0/+8
"git fetch http::/site/path" did not die correctly and segfaulted instead. * jk/fix-remote-curl-url-wo-proto: remote-curl: handle URLs without protocol
2016-09-19Merge branch 'js/t9903-chaining' into maintLibravatar Junio C Hamano1-1/+1
Test fix. * js/t9903-chaining: t9903: fix broken && chain
2016-09-19Merge branch 'ep/use-git-trace-curl-in-tests' into maintLibravatar Junio C Hamano4-9/+19
Update a few tests that used to use GIT_CURL_VERBOSE to use the newer GIT_TRACE_CURL. * ep/use-git-trace-curl-in-tests: t5551-http-fetch-smart.sh: use the GIT_TRACE_CURL environment var t5550-http-fetch-dumb.sh: use the GIT_TRACE_CURL environment var test-lib.sh: preserve GIT_TRACE_CURL from the environment t5541-http-push-smart.sh: use the GIT_TRACE_CURL environment var
2016-09-19Merge branch 'js/t6026-clean-up' into maintLibravatar Junio C Hamano1-0/+2
A test spawned a short-lived background process, which sometimes prevented the test directory from getting removed at the end of the script on some platforms. * js/t6026-clean-up: t6026-merge-attr: clean up background process at end of test case
2016-09-19Merge branch 'jc/forbid-symbolic-ref-d-HEAD' into maintLibravatar Junio C Hamano1-7/+14
"git symbolic-ref -d HEAD" happily removes the symbolic ref, but the resulting repository becomes an invalid one. Teach the command to forbid removal of HEAD. * jc/forbid-symbolic-ref-d-HEAD: symbolic-ref -d: do not allow removal of HEAD
2016-09-19Merge branch 'jc/submodule-anchor-git-dir' into maintLibravatar Junio C Hamano1-0/+35
Having a submodule whose ".git" repository is somehow corrupt caused a few commands that recurse into submodules loop forever. * jc/submodule-anchor-git-dir: submodule: avoid auto-discovery in prepare_submodule_repo_env()
2016-09-19Merge branch 'jk/test-lib-drop-pid-from-results' into maintLibravatar Junio C Hamano1-2/+2
The test framework left the number of tests and success/failure count in the t/test-results directory, keyed by the name of the test script plus the process ID. The latter however turned out not to serve any useful purpose. The process ID part of the filename has been removed. * jk/test-lib-drop-pid-from-results: test-lib: drop PID from test-results/*.count
2016-09-15t/perf/run: copy config.mak.autogen & friends to build areaLibravatar Kirill Smelkov1-1/+7
Otherwise for people who use autotools-based configure in main worktree, the performance testing results will be inconsistent as work and build trees could be using e.g. different optimization levels. See e.g. http://public-inbox.org/git/20160818175222.bmm3ivjheokf2qzl@sigill.intra.peff.net/ for example. NOTE config.status has to be copied because otherwise without it the build would want to run reconfigure this way loosing just copied config.mak.autogen. Signed-off-by: Kirill Smelkov <kirr@nexedi.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-15format-patch: show base info before email signatureLibravatar Josh Triplett1-6/+27
Any text below the "-- " for the email signature gets treated as part of the signature, and many mail clients will trim it from the quoted text for a reply. Move it above the signature, so people can reply to it more easily. Similarly, when producing the patch as a MIME attachment, the original code placed the base info after the attached part, which would be discarded. Move the base info to the end of the part, still inside the part boundary. Add tests for the exact format of the email signature, and add tests to ensure that the base info appears before the email signature when producing a plain-text output, and that it appears before the part boundary when producing a MIME attachment. Signed-off-by: Josh Triplett <josh@joshtriplett.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-14xdiff: fix merging of hunks with -W context and -u contextLibravatar René Scharfe1-0/+25
If the function context for a hunk (with -W) reaches the beginning of the next hunk then we need to merge these two -- otherwise we'd show some lines twice, which looks strange and even confuses git apply. We already do this checking and merging in xdl_emit_diff(), but forget to consider regular context (with -u or -U). Fix that by merging hunks already if function context of the first one touches or overlaps regular context of the second one. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-08Merge branch 'sg/reflog-past-root' into maintLibravatar Junio C Hamano1-1/+0
A small test clean-up for a topic introduced in v2.9.1 and later. * sg/reflog-past-root: t1410: remove superfluous 'git reflog' from the 'walk past root' test
2016-09-08Merge branch 'bw/mingw-avoid-inheriting-fd-to-lockfile' into maintLibravatar Junio C Hamano1-0/+13
The tempfile (hence its user lockfile) API lets the caller to open a file descriptor to a temporary file, write into it and then finalize it by first closing the filehandle and then either removing or renaming the temporary file. When the process spawns a subprocess after obtaining the file descriptor, and if the subprocess has not exited when the attempt to remove or rename is made, the last step fails on Windows, because the subprocess has the file descriptor still open. Open tempfile with O_CLOEXEC flag to avoid this (on Windows, this is mapped to O_NOINHERIT). * bw/mingw-avoid-inheriting-fd-to-lockfile: mingw: ensure temporary file handles are not inherited by child processes t6026-merge-attr: child processes must not inherit index.lock handles
2016-09-08Merge branch 'jk/difftool-command-not-found' into maintLibravatar Junio C Hamano1-0/+6
"git difftool" by default ignores the error exit from the backend commands it spawns, because often they signal that they found differences by exiting with a non-zero status code just like "diff" does; the exit status codes 126 and above however are special in that they are used to signal that the command is not executable, does not exist, or killed by a signal. "git difftool" has been taught to notice these exit status codes. * jk/difftool-command-not-found: difftool: always honor fatal error exit codes
2016-09-08Merge branch 'sb/checkout-explit-detach-no-advice' into maintLibravatar Junio C Hamano1-0/+23
"git checkout --detach <branch>" used to give the same advice message as that is issued when "git checkout <tag>" (or anything that is not a branch name) is given, but asking with "--detach" is an explicit enough sign that the user knows what is going on. The advice message has been squelched in this case. * sb/checkout-explit-detach-no-advice: checkout: do not mention detach advice for explicit --detach option
2016-09-08Merge branch 'rs/pull-signed-tag' into maintLibravatar Junio C Hamano1-0/+18
When "git merge-recursive" works on history with many criss-cross merges in "verbose" mode, the names the command assigns to the virtual merge bases could have overwritten each other by unintended reuse of the same piece of memory. * rs/pull-signed-tag: commit: use FLEX_ARRAY in struct merge_remote_desc merge-recursive: fix verbose output for multiple base trees commit: factor out set_merge_remote_desc() commit: use xstrdup() in get_merge_parent()
2016-09-08Merge branch 'js/test-lint-pathname' into maintLibravatar Junio C Hamano1-1/+10
The "t/" hierarchy is prone to get an unusual pathname; "make test" has been taught to make sure they do not contain paths that cannot be checked out on Windows (and the mechanism can be reusable to catch pathnames that are not portable to other platforms as need arises). * js/test-lint-pathname: t/Makefile: ensure that paths are valid on platforms we care
2016-09-08Merge branch 'jk/push-force-with-lease-creation' into maintLibravatar Junio C Hamano1-0/+38
"git push --force-with-lease" already had enough logic to allow ensuring that such a push results in creation of a ref (i.e. the receiving end did not have another push from sideways that would be discarded by our force-pushing), but didn't expose this possibility to the users. It does so now. * jk/push-force-with-lease-creation: t5533: make it pass on case-sensitive filesystems push: allow pushing new branches with --force-with-lease push: add shorthand for --force-with-lease branch creation Documentation/git-push: fix placeholder formatting
2016-09-08Merge branch 'jk/reflog-date' into maintLibravatar Junio C Hamano1-0/+3
The reflog output format is documented better, and a new format --date=unix to report the seconds-since-epoch (without timezone) has been added. * jk/reflog-date: date: clarify --date=raw description date: add "unix" format date: document and test "raw-local" mode doc/pretty-formats: explain shortening of %gd doc/pretty-formats: describe index/time formats for %gd doc/rev-list-options: explain "-g" output formats doc/rev-list-options: clarify "commit@{Nth}" for "-g" option
2016-09-08Merge branch 'jc/renormalize-merge-kill-safer-crlf' into maintLibravatar Junio C Hamano3-48/+59
"git merge" with renormalization did not work well with merge-recursive, due to "safer crlf" conversion kicking in when it shouldn't. * jc/renormalize-merge-kill-safer-crlf: merge: avoid "safer crlf" during recording of merge results convert: unify the "auto" handling of CRLF
2016-09-08Merge branch 'jk/common-main' into maintLibravatar Junio C Hamano33-43/+43
There are certain house-keeping tasks that need to be performed at the very beginning of any Git program, and programs that are not built-in commands had to do them exactly the same way as "git" potty does. It was easy to make mistakes in one-off standalone programs (like test helpers). A common "main()" function that calls cmd_main() of individual program has been introduced to make it harder to make mistakes. * jk/common-main: mingw: declare main()'s argv as const common-main: call git_setup_gettext() common-main: call restore_sigpipe_to_default() common-main: call sanitize_stdfds() common-main: call git_extract_argv0_path() add an extra level of indirection to main()
2016-09-08remote-curl: handle URLs without protocolLibravatar Jeff King1-0/+8
Generally remote-curl would never see a URL that did not have "proto:" at the beginning, as that is what tells git to run the "git-remote-proto" helper (and git-remote-http, etc, are aliases for git-remote-curl). However, the special syntax "proto::something" will run git-remote-proto with only "something" as the URL. So a malformed URL like: http::/example.com/repo.git will feed the URL "/example.com/repo.git" to git-remote-http. The resulting URL has no protocol, but the code added by 372370f (http: use credential API to handle proxy authentication, 2016-01-26) does not handle this case and segfaults. For the purposes of this code, we don't really care what the exact protocol; only whether or not it is https. So let's just assume that a missing protocol is not, and curl will handle the real error (which is that the URL is nonsense). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-07t5551-http-fetch-smart.sh: use the GIT_TRACE_CURL environment varLibravatar Elia Pinto1-3/+12
Use the new GIT_TRACE_CURL environment variable instead of the deprecated GIT_CURL_VERBOSE. Signed-off-by: Elia Pinto <gitter.spiros@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-07t5550-http-fetch-dumb.sh: use the GIT_TRACE_CURL environment varLibravatar Elia Pinto1-5/+5
Use the new GIT_TRACE_CURL environment variable instead of the deprecated GIT_CURL_VERBOSE. Signed-off-by: Elia Pinto <gitter.spiros@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-07test-lib.sh: preserve GIT_TRACE_CURL from the environmentLibravatar Elia Pinto1-0/+1
Turning on this variable can be useful when debugging http tests. It can break a few tests in t5541 if not set to an absolute path but it is not a variable that the user is likely to have enabled accidentally. Signed-off-by: Elia Pinto <gitter.spiros@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-07t5541-http-push-smart.sh: use the GIT_TRACE_CURL environment varLibravatar Elia Pinto1-1/+1
Use the new GIT_TRACE_CURL environment variable instead of the deprecated GIT_CURL_VERBOSE. Signed-off-by: Elia Pinto <gitter.spiros@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-07t6026-merge-attr: clean up background process at end of test caseLibravatar Johannes Sixt1-0/+2
The process spawned in the hook uses the test's trash directory as CWD. As long as it is alive, the directory cannot be removed on Windows. Although the test succeeds, the 'test_done' that follows produces an error message and leaves the trash directory around. Kill the process before the test case advances. Helped-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-07t9903: fix broken && chainLibravatar Johannes Sixt1-1/+1
We might wonder why our && chain check does not catch this case: The && chain check uses a strange exit code with the expectation that the second or later part of a broken && chain would not exit with this particular code. This expectation does not work in this case because __git_ps1, being the first command in the second part of the broken && chain, records the current exit code, does its work, and finally returns to the caller with the recorded exit code. This fools our && chain check. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-02symbolic-ref -d: do not allow removal of HEADLibravatar Junio C Hamano1-7/+14
If you delete the symbolic-ref HEAD from a repository, Git no longer considers the repository valid, and even "git symbolic-ref HEAD refs/heads/master" would not be able to recover from that state (although "git init" can, but that is a sure sign that you are talking about a "broken" repository). In the spirit similar to afe5d3d5 ("symbolic ref: refuse non-ref targets in HEAD", 2009-01-29), forbid removal of HEAD to avoid corrupting a repository. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-01submodule: avoid auto-discovery in prepare_submodule_repo_env()Libravatar Junio C Hamano1-0/+35
The function is used to set up the environment variable used in a subprocess we spawn in a submodule directory. The callers set up a child_process structure, find the working tree path of one submodule and set .dir field to it, and then use start_command() API to spawn the subprocess like "status", "fetch", etc. When this happens, we expect that the ".git" (either a directory or a gitfile that points at the real location) in the current working directory of the subprocess MUST be the repository for the submodule. If this ".git" thing is a corrupt repository, however, because prepare_submodule_repo_env() unsets GIT_DIR and GIT_WORK_TREE, the subprocess will see ".git", thinks it is not a repository, and attempt to find one by going up, likely to end up in finding the repository of the superproject. In some codepaths, this will cause a command run with the "--recurse-submodules" option to recurse forever. By exporting GIT_DIR=.git, disable the auto-discovery logic in the subprocess, which would instead stop it and report an error. The test illustrates existing problems in a few callsites of this function. Without this fix, "git fetch --recurse-submodules", "git status" and "git diff" keep recursing forever. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-31Merge branch 'mh/blame-worktree'Libravatar Junio C Hamano1-0/+5
* mh/blame-worktree: blame: fix segfault on untracked files
2016-08-31Merge branch 'kw/patch-ids-optim'Libravatar Junio C Hamano1-0/+0
* kw/patch-ids-optim: p3400: make test script executable
2016-08-30test-lib: drop PID from test-results/*.countLibravatar Jeff King1-2/+2
Each test run generates a "count" file in t/test-results that stores the number of successful, failed, etc tests. If you run "t1234-foo.sh", that file is named as "t/test-results/t1234-foo-$$.count" The addition of the PID there is serving no purpose, and makes analysis of the count files harder. The presence of the PID dates back to 2d84e9f (Modify test-lib.sh to output stats to t/test-results/*, 2008-06-08), but no reasoning is given there. Looking at the current code, we can see that other files we write to test-results (like *.exit and *.out) do _not_ have the PID included. So the presence of the PID does not meaningfully allow one to store the results from multiple runs anyway. Moreover, anybody wishing to read the *.count files to aggregate results has to deal with the presence of multiple files for a given test (and figure out which one is the most recent based on their timestamps!). The only consumer of these files is the aggregate.sh script, which arguably gets this wrong. If a test is run multiple times, its counts will appear multiple times in the total (I say arguably only because the desired semantics aren't documented anywhere, but I have trouble seeing how this behavior could be useful). So let's just drop the PID, which fixes aggregate.sh, and will make new features based around the count files easier to write. Note that since the count-file may already exist (when re-running a test), we also switch the "cat" from appending to truncating. The use of append here was pointless in the first place, as we expected to always write to a unique file. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-29p3400: make test script executableLibravatar René Scharfe1-0/+0
Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-29blame: fix segfault on untracked filesLibravatar Thomas Gummerer1-0/+5
Since 3b75ee9 ("blame: allow to blame paths freshly added to the index", 2016-07-16) git blame also looks at the index to determine if there is a file that was freshly added to the index. cache_name_pos returns -pos - 1 in case there is no match is found, or if the name matches, but the entry has a stage other than 0. As git blame should work for unmerged files, it uses strcmp to determine whether the name of the returned position matches, in which case the file exists, but is merely unmerged, or if the file actually doesn't exist in the index. If the repository is empty, or if the file would lexicographically be sorted as the last file in the repository, -cache_name_pos - 1 is outside of the length of the active_cache array, causing git blame to segfault. Guard against that, and die() normally to restore the old behaviour. Reported-by: Simon Ruderich <simon@ruderich.org> Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-25Merge branch 'bw/mingw-avoid-inheriting-fd-to-lockfile'Libravatar Junio C Hamano1-0/+13
The tempfile (hence its user lockfile) API lets the caller to open a file descriptor to a temporary file, write into it and then finalize it by first closing the filehandle and then either removing or renaming the temporary file. When the process spawns a subprocess after obtaining the file descriptor, and if the subprocess has not exited when the attempt to remove or rename is made, the last step fails on Windows, because the subprocess has the file descriptor still open. Open tempfile with O_CLOEXEC flag to avoid this (on Windows, this is mapped to O_NOINHERIT). * bw/mingw-avoid-inheriting-fd-to-lockfile: mingw: ensure temporary file handles are not inherited by child processes t6026-merge-attr: child processes must not inherit index.lock handles
2016-08-23mingw: ensure temporary file handles are not inherited by child processesLibravatar Ben Wijen1-1/+1
When the index is locked and child processes inherit the handle to said lock and the parent process wants to remove the lock before the child process exits, on Windows there is a problem: it won't work because files cannot be deleted if a process holds a handle on them. The symptom: Rename from 'xxx/.git/index.lock' to 'xxx/.git/index' failed. Should I try again? (y/n) Spawning child processes with bInheritHandles==FALSE would not work because no file handles would be inherited, not even the hStdXxx handles in STARTUPINFO (stdin/stdout/stderr). Opening every file with O_NOINHERIT does not work, either, as e.g. git-upload-pack expects inherited file handles. This leaves us with the only way out: creating temp files with the O_NOINHERIT flag. This flag is Windows-specific, however. For our purposes, it is equivalent to O_CLOEXEC (which does not exist on Windows), so let's just open temporary files with the O_CLOEXEC flag and map that flag to O_NOINHERIT on Windows. As Eric Wong pointed out, we need to be careful to handle the case where the Linux headers used to compile Git support O_CLOEXEC but the Linux kernel used to run Git does not: it returns an EINVAL. This fixes the test that we just introduced to demonstrate the problem. Signed-off-by: Ben Wijen <ben@wijen.net> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-19Merge branch 'ab/hooks'Libravatar Junio C Hamano1-0/+6
"git rev-parse --git-path hooks/<hook>" learned to take core.hooksPath configuration variable (introduced during 2.9 cycle) into account. * ab/hooks: rev-parse: respect core.hooksPath in --git-path
2016-08-19Merge branch 'jk/difftool-command-not-found'Libravatar Junio C Hamano1-0/+6
"git difftool" by default ignores the error exit from the backend commands it spawns, because often they signal that they found differences by exiting with a non-zero status code just like "diff" does; the exit status codes 126 and above however are special in that they are used to signal that the command is not executable, does not exist, or killed by a signal. "git difftool" has been taught to notice these exit status codes. * jk/difftool-command-not-found: difftool: always honor fatal error exit codes
2016-08-19Merge branch 'sb/checkout-explit-detach-no-advice'Libravatar Junio C Hamano1-0/+23
"git checkout --detach <branch>" used to give the same advice message as that is issued when "git checkout <tag>" (or anything that is not a branch name) is given, but asking with "--detach" is an explicit enough sign that the user knows what is going on. The advice message has been squelched in this case. * sb/checkout-explit-detach-no-advice: checkout: do not mention detach advice for explicit --detach option
2016-08-19Merge branch 'tb/t0027-raciness-fix'Libravatar Junio C Hamano1-3/+3
The t0027 test for CRLF conversion was timing dependent and flaky. * tb/t0027-raciness-fix: convert: Correct NNO tests and missing `LF will be replaced by CRLF`
2016-08-19Merge branch 'rs/pull-signed-tag'Libravatar Junio C Hamano1-0/+18
When "git merge-recursive" works on history with many criss-cross merges in "verbose" mode, the names the command assigns to the virtual merge bases could have overwritten each other by unintended reuse of the same piece of memory. * rs/pull-signed-tag: commit: use FLEX_ARRAY in struct merge_remote_desc merge-recursive: fix verbose output for multiple base trees commit: factor out set_merge_remote_desc() commit: use xstrdup() in get_merge_parent()
2016-08-18t6026-merge-attr: child processes must not inherit index.lock handlesLibravatar Ben Wijen1-0/+13
On Windows, a file cannot be removed unless all file handles to it have been released. Hence it is particularly important to close handles when spawning children (which would probably not even know that they hold on to those handles). The example chosen for this test is a custom merge driver that indeed has no idea that it blocks the deletion of index.lock. The full use case is a daemon that lives on after the merge, with subsequent invocations handing off to the daemon, thereby avoiding hefty start-up costs. We simulate this behavior by simply sleeping one second. Note that the test only fails on Windows, due to the file locking issue. Since we have no way to say "expect failure with MINGW, success otherwise", we simply skip this test on Windows for now. Signed-off-by: Ben Wijen <ben@wijen.net> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-17Merge branch 'js/test-lint-pathname'Libravatar Junio C Hamano1-1/+10
The "t/" hierarchy is prone to get an unusual pathname; "make test" has been taught to make sure they do not contain paths that cannot be checked out on Windows (and the mechanism can be reusable to catch pathnames that are not portable to other platforms as need arises). * js/test-lint-pathname: t/Makefile: ensure that paths are valid on platforms we care
2016-08-17Merge branch 'sg/reflog-past-root'Libravatar Junio C Hamano1-1/+0
A small test clean-up for a topic introduced in v2.9.1 and later. * sg/reflog-past-root: t1410: remove superfluous 'git reflog' from the 'walk past root' test
2016-08-16rev-parse: respect core.hooksPath in --git-pathLibravatar Johannes Schindelin1-0/+6
The idea of the --git-path option is not only to avoid having to prefix paths with the output of --git-dir all the time, but also to respect overrides for specific common paths inside the .git directory (e.g. `git rev-parse --git-path objects` will report the value of the environment variable GIT_OBJECT_DIRECTORY, if set). When introducing the core.hooksPath setting, we forgot to adjust git_path() accordingly. This patch fixes that. While at it, revert the special-casing of core.hooksPath in run-command.c, as it is now no longer needed. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-16t/Makefile: ensure that paths are valid on platforms we careLibravatar Johannes Schindelin1-1/+10
Some pathnames that are okay on ext4 and on HFS+ cannot be checked out on Windows. Tests that want to see operations on such paths on filesystems that support them must do so behind appropriate test prerequisites, and must not include them in the source tree (instead they should create them when they run). Otherwise, the source tree cannot even be checked out. Make sure that double-quotes, asterisk, colon, greater/less-than, question-mark, backslash, tab, vertical-bar, as well as any non-ASCII characters never appear in the pathnames with a new test-lint-* target as part of a `make test`. To that end, we call `git ls-files` (ensuring that the paths are quoted properly), relying on the fact that paths containing non-ASCII characters are quoted within double-quotes. In case that the source code does not actually live in a Git repository (e.g. when extracted from a .zip file), or that the `git` executable cannot be executed, we simply ignore the error for now; In that case, our trusty Continuous Integration will be the last line of defense and catch any problematic file name. Noticed when a topic wanted to add a pathname with '>' in it. A check like this will prevent a similar problems from happening in the future. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>