summaryrefslogtreecommitdiffstats
path: root/bundle.c (unfollow)
Commit message (Collapse)AuthorFilesLines
2016-11-04l10n: vi.po: Updated translation to v2.11.0 (2913t)Tran Ngoc Quan1-2016/+2930
Signed-off-by: Tran Ngoc Quan <vnwildman@gmail.com>
2016-11-03l10n: ko.po: Update Korean translationChangwoo Ryu1-2230/+2946
Signed-off-by: Changwoo Ryu <cwryu@debian.org>
2016-11-01l10n: git.pot: v2.11.0 round 1 (209 new, 53 removed)Jiang Xin1-1952/+2742
Generate po/git.pot from v2.11.0-rc0 for git v2.11.0 l10n round 1. Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
2016-10-31Git 2.11-rc0v2.11.0-rc0Junio C Hamano2-28/+42
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-31git-sh-setup: be explicit where to dot-source git-sh-i18n from.Anders Kaseorg1-3/+3
d323c6b641 ("i18n: git-sh-setup.sh: mark strings for translation", 2016-06-17) started to dot-source git-sh-i18n shell script library, assuming that $PATH is already adjusted for our scripts, namely, $GIT_EXEC_PATH is at the beginning of $PATH. Old contrib scripts like contrib/convert-grafts-to-replace-refs.sh and contrib/rerere-train.sh and third-party scripts like guilt may however be using this as ". $(git --exec-path)/git-sh-setup", without satisfying that assumption. Be more explicit by specifying its path prefixed with "$(git --exec-path)/". to be safe. While we’re here, move the sourcing of git-sh-i18n below the shell portability fixes. Signed-off-by: Anders Kaseorg <andersk@mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-31commit: simplify building parents listRené Scharfe1-8/+6
Push pptr down into the FROM_MERGE branch of the if/else statement, where it's actually used, and call commit_list_append() for appending elements instead of playing tricks with commit_list_insert(). Call copy_commit_list() in the amend branch instead of open-coding it. Don't bother setting pptr in the final branch as it's not used thereafter. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-30doc: fix missing "::" in config listJeff King1-1/+1
The rebase.instructionFormat option is missing its "::" to tell AsciiDoc that it's a list entry. As a result, the option name gets lumped into the description in one big paragraph. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-28pre-receive.sample: mark it executableAnders Kaseorg1-0/+0
For consistency with other hooks, make the sample hook executable. Signed-off-by: Anders Kaseorg <andersk@mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-28Git 2.10.2v2.10.2Junio C Hamano3-2/+69
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-28Documentation/fmt-merge-msg: fix markup in exampleStefan Christ1-2/+2
Use at least 4 delimiting dashes that are required for ListingBlock to get this block rendered as verbatim text. Signed-off-by: Stefan Christ <contact@stefanchrist.eu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-28valgrind: support test helpersRené Scharfe2-3/+18
Tests run with --valgrind call git commands through a wrapper script that invokes valgrind on them. This script (valgrind.sh) is in turn invoked through symlinks created for each command in t/valgrind/bin/. Since e6e7530d (test helpers: move test-* to t/helper/ subdirectory) these symlinks have been broken for test helpers -- they point to the old locations in the root of the build directory. Fix that by teaching the code for creating the links about the new location of the binaries, and do the same in the wrapper script to allow it to find its payload. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-28Getting ready for 2.11-rc0Junio C Hamano1-1/+36
... but not quite yet. A few more topics to go. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-27git-svn: do not reuse caches memoized for a different architectureGavin Lambert1-1/+11
Reusing cached data speeds up git-svn by quite a fair bit. However, if the YAML module is unavailable, the caches are written to disk in an architecture-dependent manner. That leads to problems when upgrading, say, from 32-bit to 64-bit Git for Windows. Let's just try to read those caches back if we detect the absence of the YAML module and the presence of the file, and delete the file if it could not be read back correctly. Note that the only way to catch the error when the memoized cache could not be read back is to put the call inside an `eval { ... }` block because it would die otherwise; the `eval` block should also return `1` in case of success explicitly since the function reading back the cached data does not return an appropriate value to test for success. This fixes https://github.com/git-for-windows/git/issues/233. [ew: import "retrieve" explictly, check unlink result] Signed-off-by: Gavin Lambert <github@mirality.co.nz> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Eric Wong <e@80x24.org>
2016-10-27git-compat-util: move content inside ifdef/endif guardsJeff King1-2/+2
Commit 3f2e2297b9 (add an extra level of indirection to main(), 2016-07-01) added a declaration to git-compat-util.h, but it was accidentally placed after the final #endif that guards against multiple inclusions. This doesn't have any actual impact on the code, since it's not incorrect to repeat a function declaration in C. But it's a bad habit, and makes it more likely for somebody else to make the same mistake. It also defeats gcc's optimization to avoid opening header files whose contents are completely guarded. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-26diff: handle sha1 abbreviations outside of repositoryJeff King1-4/+17
When generating diffs outside a repository (e.g., with "diff --no-index"), we may write abbreviated sha1s as part of "--raw" output or the "index" lines of "--patch" output. Since we have no object database, we never find any collisions, and these sha1s get whatever static abbreviation length is configured (typically 7). However, we do blindly look in ".git/objects" to see if any objects exist, even though we know we are not in a repository. This is usually harmless because such a directory is unlikely to exist, but could be wrong in rare circumstances. Let's instead notice when we are not in a repository and behave as if the object database is empty (i.e., just use the default abbrev length). It would perhaps make sense to be conservative and show full sha1s in that case, but showing the default abbreviation is what we've always done (and is certainly less ugly). Note that this does mean that: cd /not/a/repo GIT_OBJECT_DIRECTORY=/some/real/objdir git diff --no-index ... used to look for collisions in /some/real/objdir but now does not. This could be considered either a bugfix (we do not look at objects if we have no repository) or a regression, but it seems unlikely that anybody would care much either way. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-26diff_aligned_abbrev: use "struct oid"Jeff King3-12/+14
Since we're modifying this function anyway, it's a good time to update it to the more modern "struct oid". We can also drop some of the magic numbers in favor of GIT_SHA1_HEXSZ, along with some descriptive comments. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-26diff_unique_abbrev: rename to diff_aligned_abbrevJeff King3-11/+11
The word "align" describes how the function actually differs from find_unique_abbrev, and will make it less confusing when we add more diff-specific abbrevation functions that do not do this alignment. Since this is a globally available function, let's also move its descriptive comment to the header file, where we typically document function interfaces. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-26find_unique_abbrev: use 4-buffer ringJeff King4-19/+16
Some code paths want to format multiple abbreviated sha1s in the same output line. Because we use a single static buffer for our return value, they have to either break their output into several calls or allocate their own arrays and use find_unique_abbrev_r(). Intead, let's mimic sha1_to_hex() and use a ring of several buffers, so that the return value stays valid through multiple calls. This shortens some of the callers, and makes it harder to for them to make a silly mistake. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-26test-*-cache-tree: setup git dirJeff King2-0/+2
These test helper programs access the index, but do not ever setup_git_directory(), meaning we just blindly looked in ".git/index". This happened to work for the purposes of our tests (which do not run from subdirectories, nor in non-repos), but it's a bad habit. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-26read info/{attributes,exclude} only when in repositoryJeff King2-7/+11
The low-level attribute and gitignore code will try to look in $GIT_DIR/info for any repo-level configuration files, even if we have not actually determined that we are in a repository (e.g., running "git grep --no-index"). In such a case they end up looking for ".git/info/attributes", etc. This is generally harmless, as such a file is unlikely to exist outside of a repository, but it's still conceptually the wrong thing to do. Let's detect this situation explicitly and skip reading the file (i.e., the same behavior we'd get if we were in a repository and the file did not exist). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-26Eleventh batch for 2.11Junio C Hamano1-0/+106
There still are a few topics that need to go in before -rc0 which would make the shape of the upcoming release clearer, but here is the final batch before it happens. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-26hex: make wraparound of the index into ring-buffer explicitRené Scharfe2-2/+4
Overflow is defined for unsigned integers, but not for signed ones. We could make the ring-buffer index in sha1_to_hex() and get_pathname() unsigned to be on the safe side to resolve this, but let's make it explicit that we are wrapping around at whatever the number of elements the ring-buffer has. The compiler is smart enough to turn modulus into bitmask for these codepaths that use ring-buffers of a size that is a power of 2. Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-26stash: allow stashes to be referenced by index onlyAaron M Watson3-3/+50
Instead of referencing "stash@{n}" explicitly, make it possible to simply reference as "n". Most users only reference stashes by their position in the stash stack (what I refer to as the "index" here). The syntax for the typical stash (stash@{n}) is slightly annoying and easy to forget, and sometimes difficult to escape properly in a script. Because of this the capability to do things with the stash by simply referencing the index is desirable. This patch includes the superior implementation provided by Øsse Walle (thanks for that), with a slight change to fix a broken test in the test suite. I also merged the test scripts as suggested by Jeff King, and un-wrapped the documentation as suggested by Junio Hamano. Signed-off-by: Aaron M Watson <watsona4@gmail.com> Reviewed-by: Jeff King <peff@peff.net>
2016-10-26t0060: sidestep surprising path mangling results on WindowsJohannes Sixt1-13/+14
When an MSYS program (such as the bash that drives the test suite) invokes git on Windows, absolute Unix style paths are transformed into Windows native absolute paths (drive letter form). However, this transformation also includes some simplifications that are not just straight-forward textual substitutions: - When the path ends in "/.", then the dot is stripped, but not the directory separator. - When the path contains "..", then it is optimized away if possible, e.g., "/c/dir/foo/../bar" becomes "c:/dir/bar". These additional transformations violate the assumptions of some submodule path tests. We can avoid them when the input is already a Windows native path, because then MSYS leaves the path unmolested. Convert the uses of $PWD to $(pwd); the latter returns a native Windows path. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-25read-cache: make sure file handles are not inherited by child processesLars Schneider1-1/+8
This fixes "convert: add filter.<driver>.process option" (edcc8581) on Windows. Consider the case of a file that requires filtering and is present in branch A but not in branch B. If A is the current HEAD and we checkout B then the following happens: 1. ce_compare_data() opens the file 2. index_fd() detects that the file requires to run a clean filter and calls index_stream_convert_blob() 4. index_stream_convert_blob() calls convert_to_git_filter_fd() 5. convert_to_git_filter_fd() calls apply_filter() which creates a new long running filter process (in case it is the first file of this kind to be filtered) 6. The new filter process inherits all file handles. This is the default on Linux/OSX and is explicitly defined in the `CreateProcessW` call in `mingw.c` on Windows. 7. ce_compare_data() closes the file 8. Git unlinks the file as it is not present in B The unlink operation does not work on Windows because the filter process has still an open handle to the file. On Linux/OSX the unlink operation succeeds but the file descriptors still leak into the child process. Fix this problem by opening files in read-cache with the O_CLOEXEC flag to ensure that the file descriptor does not remain open in a newly spawned process similar to 05d1ed6148 ("mingw: ensure temporary file handles are not inherited by child processes", 2016-08-22). Signed-off-by: Lars Schneider <larsxschneider@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-25sha1_file: open window into packfiles with O_CLOEXECLars Schneider1-4/+9
All processes that the Git main process spawns inherit the open file descriptors of the main process. These leaked file descriptors can cause problems. Use the O_CLOEXEC flag similar to 05d1ed61 to fix the leaked file descriptors. Signed-off-by: Lars Schneider <larsxschneider@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-25sha1_file: rename git_open_noatime() to git_open()Lars Schneider4-9/+9
This function is meant to be used when reading from files in the object store, and the original objective was to avoid smudging atime of loose object files too often, hence its name. Because we'll be extending its role in the next commit to also arrange the file descriptors they return auto-closed in the child processes, rename it to lose "noatime" part that is too specific. Signed-off-by: Lars Schneider <larsxschneider@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-25doc: fix the 'revert a faulty merge' ASCII art tab spacingPhilip Oakley1-8/+8
The asciidoctor doc-tool stack does not always respect the 'tab = 8 spaces' rule expectation, particularly for the Git-for-Windows generated html pages. This follows on from the 'doc: fix merge-base ASCII art tab spacing' fix. Use just spaces within the block of the ascii art. All other *.txt ascii art containing three dashes has been checked. Asciidoctor correctly formats the other art blocks that do contain tabs. Signed-off-by: Philip Oakley <philipoakley@iee.org Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-24commit: don't be fooled by ita entries when creating initial commitNguyễn Thái Ngọc Duy2-3/+18
ita entries are dropped at tree generation phase. If the entire index consists of just ita entries, the result would be a a commit with no entries, which should be caught unless --allow-empty is specified. The test "!!active_nr" is not sufficient to catch this. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-24commit: fix empty commit creation when there's no changes but ita entriesNguyễn Thái Ngọc Duy5-5/+18
If i-t-a entries are present and there is no change between the index and HEAD i-t-a entries, index_differs_from() still returns "dirty, new entries" (aka, the resulting commit is not empty), but cache-tree will skip i-t-a entries and produce the exact same tree of current commit. index_differs_from() is supposed to catch this so we can abort git-commit (unless --no-empty is specified). Update it to optionally ignore i-t-a entries when doing a diff between the index and HEAD so that it would return "no change" in this case and abort commit. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-24diff: add --ita-[in]visible-in-indexNguyễn Thái Ngọc Duy3-1/+15
The option --ita-invisible-in-index exposes the "ita_invisible_in_index" diff flag to outside to allow easier experimentation with this new mode. The "plan" is to make --ita-invisible-in-index default to keep consistent behavior with 'status' and 'commit', but a bunch other commands like 'apply', 'merge', 'reset'.... need to be taken into consideration as well. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-24diff-lib: allow ita entries treated as "not yet exist in index"Nguyễn Thái Ngọc Duy5-4/+38
When comparing the index and the working tree to show which paths are new, and comparing the tree recorded in the HEAD and the index to see if committing the contents recorded in the index would result in an empty commit, we would want the former comparison to say "these are new paths" and the latter to say "there is no change" for paths that are marked as intent-to-add. We made a similar attempt at d95d728a ("diff-lib.c: adjust position of i-t-a entries in diff", 2015-03-16), which redefined the semantics of these two comparison modes globally, which was a disaster and had to be reverted at 78cc1a54 ("Revert "diff-lib.c: adjust position of i-t-a entries in diff"", 2015-06-23). To make sure we do not repeat the same mistake, introduce a new internal diffopt option so that this different semantics can be asked for only by callers that ask it, while making sure other unaudited callers will get the same comparison result. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-24daemon: detect and reject too-long pathsJeff King1-4/+21
When we are checking the path via path_ok(), we use some fixed PATH_MAX buffers. We write into them via snprintf(), so there's no possibility of overflow, but it does mean we may silently truncate the path, leading to potentially confusing errors when the partial path does not exist. We're better off to reject the path explicitly. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-24test-lib: bail out when "-v" used under "prove"Jeff King1-0/+10
When there is a TAP harness consuming the output of our test scripts, the "--verbose" breaks the output by mingling test command output with TAP. Because the TAP::Harness module used by "prove" is fairly lenient, this _usually_ works, but it violates the spec, and things get very confusing if the commands happen to output a line that looks like TAP (e.g., the word "ok" on its own line). Let's detect this situation and complain. Just calling error() isn't great, though; prove will tell us that the script failed, but the message doesn't make it through to the user. Instead, we can use the special TAP signal "Bail out!". This not only shows the message to the user, but instructs the harness to stop running the tests entirely. This is exactly what we want here, as the problem is in the command-line options, and every test script would produce the same error. The result looks like this (the first "Bailout called" line is in red if prove uses color on your terminal): $ make GIT_TEST_OPTS='--verbose --tee' rm -f -r 'test-results' *** prove *** Bailout called. Further testing stopped: verbose mode forbidden under TAP harness; try --verbose-log FAILED--Further testing stopped: verbose mode forbidden under TAP harness; try --verbose-log Makefile:39: recipe for target 'prove' failed make: *** [prove] Error 255 Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-22transport: compute summary-width dynamicallyJunio C Hamano1-1/+17
Now all that is left to do is to actually iterate over the refs and measure the display width needed to show their abbreviation. Helped-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-22transport: allow summary-width to be computed dynamicallyJunio C Hamano3-4/+9
Now we have identified three callchains that have a set of refs that they want to show their <old, new> object names in an aligned output, we can replace their reference to the constant TRANSPORT_SUMMARY_WIDTH with a helper function call to transport_summary_width() that takes the set of ref as a parameter. This step does not yet iterate over the refs and compute, which is left as an exercise to the readers. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-22fetch: pass summary_width down the callchainJunio C Hamano1-16/+21
The leaf function on the "fetch" side that uses TRANSPORT_SUMMARY_WIDTH constant is builtin/fetch.c::format_display() and it has two distinct callchains. The one that reports the primary result of fetch originates at store_updated_refs(); the other one that reports the pruning of the remote-tracking refs originates at prune_refs(). Teach these two places to pass summary_width down the callchain, just like we did for the "push" side in the previous commit. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-21transport: pass summary_width down the callchainJunio C Hamano1-25/+38
The callchain that originates at transport_print_push_status() eventually hits a single leaf function, print_ref_status(), that is used to show from what old object to what new object a ref got updated, and the width of the part that shows old and new object names used a constant TRANSPORT_SUMMARY_WIDTH. Teach the callchain to pass the width down from the top instead. This allows a future enhancement to compute the necessary display width before calling down this callchain. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-21trailer: support values folded to multiple linesJonathan Tan3-10/+211
Currently, interpret-trailers requires that a trailer be only on 1 line. For example: a: first line second line would be interpreted as one trailer line followed by one non-trailer line. Make interpret-trailers support RFC 822-style folding, treating those lines as one logical trailer. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-21trailer: forbid leading whitespace in trailersJonathan Tan3-2/+17
Currently, interpret-trailers allows leading whitespace in trailer lines. This leads to false positives, especially for quoted lines or bullet lists. Forbid leading whitespace in trailers. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-21trailer: allow non-trailers in trailer blockJonathan Tan3-15/+194
Currently, interpret-trailers requires all lines of a trailer block to be trailers (or comments) - if not it would not identify that block as a trailer block, and thus create its own trailer block, inserting a blank line. For example: echo -e "\nSigned-off-by: x\nnot trailer" | git interpret-trailers --trailer "c: d" would result in: Signed-off-by: x not trailer c: d Relax the definition of a trailer block to require that the trailers (i) are all trailers, or (ii) contain at least one Git-generated trailer and consists of at least 25% trailers. Signed-off-by: x not trailer c: d (i) is the existing functionality. (ii) allows arbitrary lines to be included in trailer blocks, like those in [1], and still allow interpret-trailers to be used. [1] https://kernel.googlesource.com/pub/scm/linux/kernel/git/stable/linux-stable/+/e7d316a02f683864a12389f8808570e37fb90aa3 Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-21trailer: clarify failure modes in parse_trailerJonathan Tan1-22/+53
The parse_trailer function has a few modes of operation, all depending on whether the separator is present in its input, and if yes, the separator's position. Some of these modes are failure modes, and these failure modes are handled differently depending on whether the trailer line was sourced from a file or from a command-line argument. Extract a function to find the separator, allowing the invokers of parse_trailer to determine how to handle the failure modes instead of making parse_trailer do it. In this function, also take in the list of separators, so that we can distinguish between command line arguments (which allow '=' as separator) and file input (which does not allow '=' as separator). Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-21travis: use --verbose-log test optionJeff King1-1/+1
Because we run the tests via "prove", the output from "--verbose" may interfere with our TAP output. Using "--verbose-log" solves this while letting us retain our on-disk log. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-21test-lib: add --verbose-log optionJeff King2-3/+25
The "--verbose" option redirects output from arbitrary test commands to stdout. This is useful for examining the output manually, like: ./t5547-push-quarantine.sh -v | less But it also means that the output is intermingled with the TAP directives, which can confuse a TAP parser like "prove". This has always been a potential problem, but became an issue recently when one test happened to output the word "ok" on a line by itself, which prove interprets as a test success: $ prove t5547-push-quarantine.sh :: -v t5547-push-quarantine.sh .. 1/? To dest.git * [new branch] HEAD -> master To dest.git ! [remote rejected] reject -> reject (pre-receive hook declined) error: failed to push some refs to 'dest.git' fatal: git cat-file d08c8eba97f4e683ece08654c7c8d2ba0c03b129: bad file t5547-push-quarantine.sh .. Failed -1/4 subtests Test Summary Report ------------------- t5547-push-quarantine.sh (Wstat: 0 Tests: 5 Failed: 0) Parse errors: Tests out of sequence. Found (2) but expected (3) Tests out of sequence. Found (3) but expected (4) Tests out of sequence. Found (4) but expected (5) Bad plan. You planned 4 tests but ran 5. Files=1, Tests=5, 0 wallclock secs ( 0.01 usr + 0.01 sys = 0.02 CPU) Result: FAIL One answer is "if it hurts, don't do it", but that's not quite the whole story. The Travis tests use "--verbose --tee" so that they can get the benefit of prove's parallel options, along with a verbose log in case there is a failure. We just need the verbose output to go to the log, but keep stdout clean. Getting this right turns out to be surprisingly difficult. Here's the progression of alternatives I considered: 1. Add an option to write verbose output to stderr. This is hard to capture, though, because we want each test to have its own log (because they're all run in parallel and the jumbled output would be useless). 2. Add an option to write verbose output to a file in test-results. This works, but the log is missing all of the non-verbose output, which gives context. 3. Like (2), but teach say_color() to additionally output to the log. This mostly works, but misses any output that happens outside of the say() functions (which isn't a lot, but is a potential maintenance headache). 4. Like (2), but make the log file the same as the "--tee" file. That almost works, but now we have two processes opening the same file. That gives us two separate descriptors, each with their own idea of the current position. They'll each start writing at offset 0, and overwrite each other's data. 5. Like (4), but in each case open the file for appending. That atomically positions each write at the end of the file. It's possible we may still get sheared writes between the two processes, but this is already the case when writing to stdout. It's not a problem in practice because the test harness generally waits for snippets to finish before writing the TAP output. We can ignore buffering issues with tee, because POSIX mandates that it does not buffer. Likewise, POSIX specifies "tee -a", so it should be available everywhere. This patch implements option (5), which seems to work well in practice. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-21test-lib: handle TEST_OUTPUT_DIRECTORY with spacesJeff King1-2/+2
We are careful in test_done to handle a results directory with a space in it, but the "--tee" code path does not. Doing: export TEST_OUTPUT_DIRECTORY='/tmp/path with spaces' ./t000-init.sh --tee results in errors. Let's consistently double-quote our path variables so that this works. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-21Git.pm: add comment pointing to t9000Matthieu Moy1-0/+2
parse_mailboxes should probably eventually be completely equivalent to Mail::Address, and if this happens we can drop the Mail::Address dependency. Add a comment in the code reminding the current state of the code, and point to the corresponding failing test to help future contributors to get it right. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-21t9000-addresses: update expected results after fixMatthieu Moy1-4/+4
e3fdbcc8e1 (parse_mailboxes: accept extra text after <...> address, 2016-10-13) improved our in-house address parser and made it closer to Mail::Address. As a consequence, some tests comparing it to Mail::Address now pass, but e3fdbcc8e1 forgot to update the test. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-21doc: fix merge-base ASCII art tab spacingPhilip Oakley1-13/+13
The doc-tool stack does not always respect the 'tab = 8 spaces' rule, particularly the git-scm doc pages https://git-scm.com/docs/git-merge-base and the Git generated html pages. Use just spaces within the block of the ascii art. Noticed when reviewing Junio's suggested update to `git merge-base` https://public-inbox.org/git/xmqqmvi2sj8f.fsf@gitster.mtv.corp.google.com/T/#u Signed-off-by: Philip Oakley <philipoakley@iee.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-21sequencer: mark all error messages for translationJohannes Schindelin1-10/+16
There was actually only one error message that was not yet marked for translation. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-21sequencer: start error messages consistently with lower caseJohannes Schindelin2-35/+35
Quite a few error messages touched by this developer during the work to speed up rebase -i started with an upper case letter, violating our current conventions. Instead of sneaking in this fix (and forgetting quite a few error messages), let's just have one wholesale patch fixing all of the error messages in the sequencer. While at it, the funny "error: Error wrapping up..." was changed to a less funny, but more helpful, "error: failed to finalize...". Pointed out by Junio Hamano. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>