summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
2018-09-27fsck: detect submodule paths starting with dashLibravatar Jeff King1-0/+8
As with urls, submodule paths with dashes are ignored by git, but may end up confusing older versions. Detecting them via fsck lets us prevent modern versions of git from being a vector to spread broken .gitmodules to older versions. Compared to blocking leading-dash urls, though, this detection may be less of a good idea: 1. While such paths provide confusing and broken results, they don't seem to actually work as option injections against anything except "cd". In particular, the submodule code seems to canonicalize to an absolute path before running "git clone" (so it passes /your/clone/-sub). 2. It's more likely that we may one day make such names actually work correctly. Even after we revert this fsck check, it will continue to be a hassle until hosting servers are all updated. On the other hand, it's not entirely clear that the behavior in older versions is safe. And if we do want to eventually allow this, we may end up doing so with a special syntax anyway (e.g., writing "./-sub" in the .gitmodules file, and teaching the submodule code to canonicalize it when comparing). So on balance, this is probably a good protection. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-09-27fsck: detect submodule urls starting with dashLibravatar Jeff King1-0/+15
Urls with leading dashes can cause mischief on older versions of Git. We should detect them so that they can be rejected by receive.fsckObjects, preventing modern versions of git from being a vector by which attacks can spread. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-09-27Sync with 2.16.5Libravatar Junio C Hamano2-0/+54
* maint-2.16: Git 2.16.5 Git 2.15.3 Git 2.14.5 submodule-config: ban submodule paths that start with a dash submodule-config: ban submodule urls that start with dash submodule--helper: use "--" to signal end of clone options
2018-09-27Sync with 2.15.3Libravatar Junio C Hamano2-0/+54
* maint-2.15: Git 2.15.3 Git 2.14.5 submodule-config: ban submodule paths that start with a dash submodule-config: ban submodule urls that start with dash submodule--helper: use "--" to signal end of clone options
2018-09-27Sync with Git 2.14.4Libravatar Junio C Hamano2-0/+54
* maint-2.14: Git 2.14.5 submodule-config: ban submodule paths that start with a dash submodule-config: ban submodule urls that start with dash submodule--helper: use "--" to signal end of clone options
2018-09-27submodule-config: ban submodule paths that start with a dashLibravatar Jeff King1-0/+20
We recently banned submodule urls that look like command-line options. This is the matching change to ban leading-dash paths. As with the urls, this should not break any use cases that currently work. Even with our "--" separator passed to git-clone, git-submodule.sh gets confused. Without the code portion of this patch, the clone of "-sub" added in t7417 would yield results like: /path/to/git-submodule: 410: cd: Illegal option -s /path/to/git-submodule: 417: cd: Illegal option -s /path/to/git-submodule: 410: cd: Illegal option -s /path/to/git-submodule: 417: cd: Illegal option -s Fetched in submodule path '-sub', but it did not contain b56243f8f4eb91b2f1f8109452e659f14dd3fbe4. Direct fetching of that commit failed. Moreover, naively adding such a submodule doesn't work: $ git submodule add $url -sub The following path is ignored by one of your .gitignore files: -sub even though there is no such ignore pattern (the test script hacks around this with a well-placed "git mv"). Unlike leading-dash urls, though, it's possible that such a path _could_ be useful if we eventually made it work. So this commit should be seen not as recommending a particular policy, but rather temporarily closing off a broken and possibly dangerous code-path. We may revisit this decision later. There are two minor differences to the tests in t7416 (that covered urls): 1. We don't have a "./-sub" escape hatch to make this work, since the submodule code expects to be able to match canonical index names to the path field (so you are free to add submodule config with that path, but we would never actually use it, since an index entry would never start with "./"). 2. After this patch, cloning actually succeeds. Since we ignore the submodule.*.path value, we fail to find a config stanza for our submodule at all, and simply treat it as inactive. We still check for the "ignoring" message. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-09-27submodule-config: ban submodule urls that start with dashLibravatar Jeff King1-0/+34
The previous commit taught the submodule code to invoke our "git clone $url $path" with a "--" separator so that we aren't confused by urls or paths that start with dashes. However, that's just one code path. It's not clear if there are others, and it would be an easy mistake to add one in the future. Moreover, even with the fix in the previous commit, it's quite hard to actually do anything useful with such an entry. Any url starting with a dash must fall into one of three categories: - it's meant as a file url, like "-path". But then any clone is not going to have the matching path, since it's by definition relative inside the newly created clone. If you spell it as "./-path", the submodule code sees the "/" and translates this to an absolute path, so it at least works (assuming the receiver has the same filesystem layout as you). But that trick does not apply for a bare "-path". - it's meant as an ssh url, like "-host:path". But this already doesn't work, as we explicitly disallow ssh hostnames that begin with a dash (to avoid option injection against ssh). - it's a remote-helper scheme, like "-scheme::data". This _could_ work if the receiver bends over backwards and creates a funny-named helper like "git-remote--scheme". But normally there would not be any helper that matches. Since such a url does not work today and is not likely to do anything useful in the future, let's simply disallow them entirely. That protects the existing "git clone" path (in a belt-and-suspenders way), along with any others that might exist. Our tests cover two cases: 1. A file url with "./" continues to work, showing that there's an escape hatch for people with truly silly repo names. 2. A url starting with "-" is rejected. Note that we expect case (2) to fail, but it would have done so even without this commit, for the reasons given above. So instead of just expecting failure, let's also check for the magic word "ignoring" on stderr. That lets us know that we failed for the right reason. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-22Sync with Git 2.15.2Libravatar Junio C Hamano3-0/+182
* maint-2.15: Git 2.15.2 Git 2.14.4 Git 2.13.7 verify_path: disallow symlinks in .gitmodules update-index: stat updated files earlier verify_dotfile: mention case-insensitivity in comment verify_path: drop clever fallthrough skip_prefix: add case-insensitive variant is_{hfs,ntfs}_dotgitmodules: add tests is_ntfs_dotgit: match other .git files is_hfs_dotgit: match other .git files is_ntfs_dotgit: use a size_t for traversing string submodule-config: verify submodule names as paths
2018-05-22Sync with Git 2.14.4Libravatar Junio C Hamano3-0/+182
* maint-2.14: Git 2.14.4 Git 2.13.7 verify_path: disallow symlinks in .gitmodules update-index: stat updated files earlier verify_dotfile: mention case-insensitivity in comment verify_path: drop clever fallthrough skip_prefix: add case-insensitive variant is_{hfs,ntfs}_dotgitmodules: add tests is_ntfs_dotgit: match other .git files is_hfs_dotgit: match other .git files is_ntfs_dotgit: use a size_t for traversing string submodule-config: verify submodule names as paths
2018-05-22Sync with Git 2.13.7Libravatar Junio C Hamano3-0/+182
* maint-2.13: Git 2.13.7 verify_path: disallow symlinks in .gitmodules update-index: stat updated files earlier verify_dotfile: mention case-insensitivity in comment verify_path: drop clever fallthrough skip_prefix: add case-insensitive variant is_{hfs,ntfs}_dotgitmodules: add tests is_ntfs_dotgit: match other .git files is_hfs_dotgit: match other .git files is_ntfs_dotgit: use a size_t for traversing string submodule-config: verify submodule names as paths
2018-05-21fsck: complain when .gitmodules is a symlinkLibravatar Jeff King1-0/+29
We've recently forbidden .gitmodules to be a symlink in verify_path(). And it's an easy way to circumvent our fsck checks for .gitmodules content. So let's complain when we see it. Signed-off-by: Jeff King <peff@peff.net>
2018-05-21index-pack: check .gitmodules files with --strictLibravatar Jeff King2-0/+50
Now that the internal fsck code has all of the plumbing we need, we can start checking incoming .gitmodules files. Naively, it seems like we would just need to add a call to fsck_finish() after we've processed all of the objects. And that would be enough to cover the initial test included here. But there are two extra bits: 1. We currently don't bother calling fsck_object() at all for blobs, since it has traditionally been a noop. We'd actually catch these blobs in fsck_finish() at the end, but it's more efficient to check them when we already have the object loaded in memory. 2. The second pass done by fsck_finish() needs to access the objects, but we're actually indexing the pack in this process. In theory we could give the fsck code a special callback for accessing the in-pack data, but it's actually quite tricky: a. We don't have an internal efficient index mapping oids to packfile offsets. We only generate it on the fly as part of writing out the .idx file. b. We'd still have to reconstruct deltas, which means we'd basically have to replicate all of the reading logic in packfile.c. Instead, let's avoid running fsck_finish() until after we've written out the .idx file, and then just add it to our internal packed_git list. This does mean that the objects are "in the repository" before we finish our fsck checks. But unpack-objects already exhibits this same behavior, and it's an acceptable tradeoff here for the same reason: the quarantine mechanism means that pushes will be fully protected. In addition to a basic push test in t7415, we add a sneaky pack that reverses the usual object order in the pack, requiring that index-pack access the tree and blob during the "finish" step. This already works for unpack-objects (since it will have written out loose objects), but we'll check it with this sneaky pack for good measure. Signed-off-by: Jeff King <peff@peff.net>
2018-05-21unpack-objects: call fsck_finish() after fscking objectsLibravatar Jeff King1-0/+7
As with the previous commit, we must call fsck's "finish" function in order to catch any queued objects for .gitmodules checks. This second pass will be able to access any incoming objects, because we will have exploded them to loose objects by now. This isn't quite ideal, because it means that bad objects may have been written to the object database (and a subsequent operation could then reference them, even if the other side doesn't send the objects again). However, this is sufficient when used with receive.fsckObjects, since those loose objects will all be placed in a temporary quarantine area that will get wiped if we find any problems. Signed-off-by: Jeff King <peff@peff.net>
2018-05-21fsck: call fsck_finish() after fscking objectsLibravatar Jeff King1-0/+4
Now that the internal fsck code is capable of checking .gitmodules files, we just need to teach its callers to use the "finish" function to check any queued objects. With this, we can now catch the malicious case in t7415 with git-fsck. Signed-off-by: Jeff King <peff@peff.net>
2018-05-21Merge branch 'jk/submodule-name-verify-fix' into jk/submodule-name-verify-fsckLibravatar Jeff King3-0/+182
* jk/submodule-name-verify-fix: verify_path: disallow symlinks in .gitmodules update-index: stat updated files earlier verify_path: drop clever fallthrough skip_prefix: add icase-insensitive variant is_{hfs,ntfs}_dotgitmodules: add tests path: match NTFS short names for more .git files is_hfs_dotgit: match other .git files is_ntfs_dotgit: use a size_t for traversing string submodule-config: verify submodule names as paths Note that this includes two bits of evil-merge: - there's a new call to verify_path() that doesn't actually have a mode available. It should be OK to pass "0" here, since we're just manipulating the untracked cache, not an actual index entry. - the lstat() in builtin/update-index.c:update_one() needs to be updated to handle the fsmonitor case (without this it still behaves correctly, but does an unnecessary lstat).
2018-05-21is_{hfs,ntfs}_dotgitmodules: add testsLibravatar Johannes Schindelin2-0/+106
This tests primarily for NTFS issues, but also adds one example of an HFS+ issue. Thanks go to Congyi Wu for coming up with the list of examples where NTFS would possibly equate the filename with `.gitmodules`. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Jeff King <peff@peff.net>
2018-05-21submodule-config: verify submodule names as pathsLibravatar Jeff King1-0/+76
Submodule "names" come from the untrusted .gitmodules file, but we blindly append them to $GIT_DIR/modules to create our on-disk repo paths. This means you can do bad things by putting "../" into the name (among other things). Let's sanity-check these names to avoid building a path that can be exploited. There are two main decisions: 1. What should the allowed syntax be? It's tempting to reuse verify_path(), since submodule names typically come from in-repo paths. But there are two reasons not to: a. It's technically more strict than what we need, as we really care only about breaking out of the $GIT_DIR/modules/ hierarchy. E.g., having a submodule named "foo/.git" isn't actually dangerous, and it's possible that somebody has manually given such a funny name. b. Since we'll eventually use this checking logic in fsck to prevent downstream repositories, it should be consistent across platforms. Because verify_path() relies on is_dir_sep(), it wouldn't block "foo\..\bar" on a non-Windows machine. 2. Where should we enforce it? These days most of the .gitmodules reads go through submodule-config.c, so I've put it there in the reading step. That should cover all of the C code. We also construct the name for "git submodule add" inside the git-submodule.sh script. This is probably not a big deal for security since the name is coming from the user anyway, but it would be polite to remind them if the name they pick is invalid (and we need to expose the name-checker to the shell anyway for our test scripts). This patch issues a warning when reading .gitmodules and just ignores the related config entry completely. This will generally end up producing a sensible error, as it works the same as a .gitmodules file which is missing a submodule entry (so "submodule update" will barf, but "git clone --recurse-submodules" will print an error but not abort the clone. There is one minor oddity, which is that we print the warning once per malformed config key (since that's how the config subsystem gives us the entries). So in the new test, for example, the user would see three warnings. That's OK, since the intent is that this case should never come up outside of malicious repositories (and then it might even benefit the user to see the message multiple times). Credit for finding this vulnerability and the proof of concept from which the test script was adapted goes to Etienne Stalmans. Signed-off-by: Jeff King <peff@peff.net>
2018-03-28Merge branch 'nd/parseopt-completion'Libravatar Junio C Hamano1-0/+31
Hotfix for recently graduated topic that give help to completion scripts from the Git subcommands that are being completed * nd/parseopt-completion: t9902: disable test on the list of merge-strategies under GETTEXT_POISON completion: clear cached --options when sourcing the completion script
2018-03-23t9902: disable test on the list of merge-strategies under GETTEXT_POISONLibravatar Junio C Hamano1-1/+1
The code to learn the list of merge strategies from the output of "git merge -s help" forces C locale, so that it can notice the message shown to indicate where the list starts in the output. However, GETTEXT_POISON build corrupts its output even when run in the C locale, and we cannot expect this test to succeed. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-22Merge branch 'jk/cached-commit-buffer' into maintLibravatar Junio C Hamano1-31/+0
Code clean-up. * jk/cached-commit-buffer: revision: drop --show-all option commit: drop uses of get_cached_commit_buffer()
2018-03-22Merge branch 'sm/mv-dry-run-update' into maintLibravatar Junio C Hamano1-0/+6
Code clean-up. * sm/mv-dry-run-update: mv: remove unneeded 'if (!show_only)' t7001: add test case for --dry-run
2018-03-22Merge branch 'gs/test-unset-xdg-cache-home' into maintLibravatar Junio C Hamano1-0/+1
Test update. * gs/test-unset-xdg-cache-home: test-lib.sh: unset XDG_CACHE_HOME
2018-03-22Merge branch 'rd/typofix' into maintLibravatar Junio C Hamano2-2/+2
Typofix. * rd/typofix: Correct mispellings of ".gitmodule" to ".gitmodules" t/: correct obvious typo "detahced"
2018-03-22Merge branch 'sg/doc-test-must-fail-args' into maintLibravatar Junio C Hamano2-2/+22
Devdoc update. * sg/doc-test-must-fail-args: t: document 'test_must_fail ok=<signal-name>'
2018-03-22Merge branch 'jk/gettext-poison' into maintLibravatar Junio C Hamano1-4/+0
Test updates. * jk/gettext-poison: git-sh-i18n: check GETTEXT_POISON before USE_GETTEXT_SCHEME t0205: drop redundant test
2018-03-22Merge branch 'nd/shared-index-fix' into maintLibravatar Junio C Hamano1-0/+19
Code clean-up. * nd/shared-index-fix: read-cache: don't write index twice if we can't write shared index read-cache.c: move tempfile creation/cleanup out of write_shared_index read-cache.c: change type of "temp" in write_shared_index()
2018-03-22Merge branch 'cl/t9001-cleanup' into maintLibravatar Junio C Hamano1-10/+7
Test clean-up. * cl/t9001-cleanup: t9001: use existing helper in send-email test
2018-03-22Merge branch 'sg/test-i18ngrep' into maintLibravatar Junio C Hamano8-43/+72
Test fixes. * sg/test-i18ngrep: t: make 'test_i18ngrep' more informative on failure t: validate 'test_i18ngrep's parameters t: move 'test_i18ncmp' and 'test_i18ngrep' to 'test-lib-functions.sh' t5536: let 'test_i18ngrep' read the file without redirection t5510: consolidate 'grep' and 'test_i18ngrep' patterns t4001: don't run 'git status' upstream of a pipe t6022: don't run 'git merge' upstream of a pipe t5812: add 'test_i18ngrep's missing filename parameter t5541: add 'test_i18ngrep's missing filename parameter
2018-03-22Merge branch 'jk/daemon-fixes' into maintLibravatar Junio C Hamano3-11/+101
Assorted fixes to "git daemon". * jk/daemon-fixes: daemon: fix length computation in newline stripping t/lib-git-daemon: add network-protocol helpers daemon: handle NULs in extended attribute string daemon: fix off-by-one in logging extended attributes t/lib-git-daemon: record daemon log t5570: use ls-remote instead of clone for interp tests
2018-03-22Merge branch 'tg/split-index-fixes' into maintLibravatar Junio C Hamano1-0/+19
The split-index mode had a few corner case bugs fixed. * tg/split-index-fixes: travis: run tests with GIT_TEST_SPLIT_INDEX split-index: don't write cache tree with null oid entries read-cache: fix reading the shared index for other repos
2018-03-22Merge branch 'jt/http-redact-cookies' into maintLibravatar Junio C Hamano1-0/+33
The http tracing code, often used to debug connection issues, learned to redact potentially sensitive information from its output so that it can be more safely sharable. * jt/http-redact-cookies: http: support omitting data from traces http: support cookie redaction when tracing
2018-03-22completion: clear cached --options when sourcing the completion scriptLibravatar SZEDER Gábor1-0/+31
The established way to update the completion script in an already running shell is to simply source it again: this brings in any new --options and features, and clears caching variables. E.g. it clears the variables caching the list of (all|porcelain) git commands, so when they are later lazy-initialized again, then they will list and cache any newly installed commmands as well. Unfortunately, since d401f3debc (git-completion.bash: introduce __gitcomp_builtin, 2018-02-09) and subsequent patches this doesn't work for a lot of git commands' options. To eliminate a lot of hard-to-maintain hard-coded lists of options, those commits changed the completion script to use a bunch of programmatically created and lazy-initialized variables to cache the options of those builtin porcelain commands that use parse-options. These variables are not cleared upon sourcing the completion script, therefore they continue caching the old lists of options, even when some commands recently learned new options or when deprecated options were removed. Always 'unset' these variables caching the options of builtin commands when sourcing the completion script. Redirect 'unset's stderr to /dev/null, because ZSH's 'unset' complains if it's invoked without any arguments, i.e. no variables caching builtin's options are set. This can happen, if someone were to source the completion script twice without completing any --options in between. Bash stays silent in this case. Add tests to ensure that these variables are indeed cleared when the completion script is sourced; not just the variables caching options, but all other caching variables, i.e. the variables caching commands, porcelain commands and merge strategies as well. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-21Merge branch 'ks/t3200-typofix'Libravatar Junio C Hamano1-1/+1
Test typofix. * ks/t3200-typofix: t/t3200: fix a typo in a test description
2018-03-21Merge branch 'jt/transfer-fsck-with-promissor'Libravatar Junio C Hamano2-0/+16
The transfer.fsckobjects configuration tells "git fetch" to validate the data and connected-ness of objects in the received pack; the code to perform this check has been taught about the narrow clone's convention that missing objects that are reachable from objects in a pack that came from a promissor remote is OK. * jt/transfer-fsck-with-promissor: fetch-pack: do not check links for partial fetch index-pack: support checking objects but not links
2018-03-21Merge branch 'ma/config-page-only-in-list-mode'Libravatar Junio C Hamano1-7/+42
In a way similar to how "git tag" learned to honor the pager setting only in the list mode, "git config" learned to ignore the pager setting when it is used for setting values (i.e. when the purpose of the operation is not to "show"). * ma/config-page-only-in-list-mode: config: change default of `pager.config` to "on" config: respect `pager.config` in list/get-mode only t7006: add tests for how git config paginates
2018-03-15Merge branch 'sg/cvs-tests-with-x'Libravatar Junio C Hamano2-9/+7
Allow running a couple of tests with "sh -x". * sg/cvs-tests-with-x: t9402-git-cvsserver-refs: don't check the stderr of a subshell t9400-git-cvsserver-server: don't rely on the output of 'test_cmp'
2018-03-15Merge branch 'cl/send-email-reply-to'Libravatar Junio C Hamano1-0/+2
"git send-email" learned "--reply-to=<address>" option. * cl/send-email-reply-to: send-email: support separate Reply-To address send-email: rename variable for clarity
2018-03-15t/t3200: fix a typo in a test descriptionLibravatar Kaartic Sivaraam1-1/+1
Signed-off-by: Kaartic Sivaraam <kaartic.sivaraam@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-15fetch-pack: do not check links for partial fetchLibravatar Jonathan Tan1-0/+11
When doing a partial clone or fetch with transfer.fsckobjects=1, use the --fsck-objects instead of the --strict flag when invoking index-pack so that links are not checked, only objects. This is because incomplete links are expected when doing a partial clone or fetch. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-15index-pack: support checking objects but not linksLibravatar Jonathan Tan1-0/+5
The index-pack command currently supports the --check-self-contained-and-connected argument, for internal use only, that instructs it to only check for broken links and not broken objects. For partial clones, we need the inverse, so add a --fsck-objects argument that checks for broken objects and not broken links, also for internal use only. This will be used by fetch-pack in a subsequent patch. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-14Merge branch 'nd/parseopt-completion'Libravatar Junio C Hamano1-5/+7
Teach parse-options API an option to help the completion script, and make use of the mechanism in command line completion. * nd/parseopt-completion: (45 commits) completion: more subcommands in _git_notes() completion: complete --{reuse,reedit}-message= for all notes subcmds completion: simplify _git_notes completion: don't set PARSE_OPT_NOCOMPLETE on --rerere-autoupdate completion: use __gitcomp_builtin in _git_worktree completion: use __gitcomp_builtin in _git_tag completion: use __gitcomp_builtin in _git_status completion: use __gitcomp_builtin in _git_show_branch completion: use __gitcomp_builtin in _git_rm completion: use __gitcomp_builtin in _git_revert completion: use __gitcomp_builtin in _git_reset completion: use __gitcomp_builtin in _git_replace remote: force completing --mirror= instead of --mirror completion: use __gitcomp_builtin in _git_remote completion: use __gitcomp_builtin in _git_push completion: use __gitcomp_builtin in _git_pull completion: use __gitcomp_builtin in _git_notes completion: use __gitcomp_builtin in _git_name_rev completion: use __gitcomp_builtin in _git_mv completion: use __gitcomp_builtin in _git_merge_base ...
2018-03-14Merge branch 'jk/add-i-diff-filter'Libravatar Junio C Hamano1-0/+20
The "interactive.diffFilter" used by "git add -i" must retain one-to-one correspondence between its input and output, but it was not enforced and caused end-user confusion. We now at least make sure the filtered result has the same number of lines as its input to detect a broken filter. * jk/add-i-diff-filter: add--interactive: detect bogus diffFilter output t3701: add a test for interactive.diffFilter
2018-03-14Merge branch 'nd/worktree-move'Libravatar Junio C Hamano1-1/+84
"git worktree" learned move and remove subcommands. * nd/worktree-move: t2028: fix minor error and issues in newly-added "worktree move" tests worktree remove: allow it when $GIT_WORK_TREE is already gone worktree remove: new command worktree move: refuse to move worktrees with submodules worktree move: accept destination as directory worktree move: new command worktree.c: add update_worktree_location() worktree.c: add validate_worktree()
2018-03-14Merge branch 'pw/add-p-recount'Libravatar Junio C Hamano1-130/+165
"git add -p" has been lazy in coalescing split patches before passing the result to underlying "git apply", leading to corner case bugs; the logic to prepare the patch to be applied after hunk selections has been tightened. * pw/add-p-recount: add -p: don't rely on apply's '--recount' option add -p: fix counting when splitting and coalescing add -p: calculate offset delta for edited patches add -p: adjust offsets of subsequent hunks when one is skipped t3701: add failing test for pathological context lines t3701: don't hard code sha1 hash values t3701: use test_write_lines and write_script t3701: indent here documents add -i: add function to format hunk header
2018-03-14Merge branch 'sg/test-x'Libravatar Junio C Hamano11-61/+93
Running test scripts under -x option of the shell is often not a useful way to debug them, because the error messages from the commands tests try to capture and inspect are contaminated by the tracing output by the shell. An earlier work done to make it more pleasant to run tests under -x with recent versions of bash is extended to cover posix shells that do not support BASH_XTRACEFD. * sg/test-x: travis-ci: run tests with '-x' tracing t/README: add a note about don't saving stderr of compound commands t1510-repo-setup: mark as untraceable with '-x' t9903-bash-prompt: don't check the stderr of __git_ps1() t5570-git-daemon: don't check the stderr of a subshell t5526: use $TRASH_DIRECTORY to specify the path of GIT_TRACE log file t5500-fetch-pack: don't check the stderr of a subshell t3030-merge-recursive: don't check the stderr of a subshell t1507-rev-parse-upstream: don't check the stderr of a shell function t: add means to disable '-x' tracing for individual test scripts t: prevent '-x' tracing from interfering with test helpers' stderr
2018-03-14Merge branch 'rj/test-i18ngrep'Libravatar Junio C Hamano2-21/+6
Test updates. * rj/test-i18ngrep: t5536: simplify checking of messages output to stderr t4151: consolidate multiple calls to test_i18ngrep
2018-03-14Merge branch 'nd/diff-stat-with-summary'Libravatar Junio C Hamano5-0/+37
"git diff" and friends learned "--compact-summary" that shows the information usually given with the "--summary" option on the same line as the diffstat output of the "--stat" option (which saves vertical space and keeps info on a single path at the same place). * nd/diff-stat-with-summary: diff: add --compact-summary diff.c: refactor pprint_rename() to use strbuf
2018-03-08t9402-git-cvsserver-refs: don't check the stderr of a subshellLibravatar SZEDER Gábor1-4/+4
Four 'cvs diff' related tests in 't9402-git-cvsserver-refs.sh' fail when the test script is run with '-x' tracing (and using a shell other than a Bash version supporting BASH_XTRACEFD). The reason for those failures is that the tests check the emptiness of a subshell's stderr, which includes the trace of commands executed in that subshell as well, throwing off the emptiness check. Save the stdout and stderr of the invoked 'cvs' command instead of the whole subshell, so the latter remains free from tracing output. (Note that changing how stdout is saved is only done for the sake of consistency, it's not necessary for correctness.) After this change t9402 passes with '-x', even when running with /bin/sh. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-08t9400-git-cvsserver-server: don't rely on the output of 'test_cmp'Libravatar SZEDER Gábor1-5/+3
The test 'cvs update (-p)' redirects and checks 'test_cmp's stdout and even its stderr. The commit introducing this test in 6e8937a084 (cvsserver: Add test for update -p, 2008-03-27) doesn't discuss why, in fact its log message only consists of that subject line. Anyway, weird as it is, it kind of made sense due to the way that test was structured: After a bit of preparation, this test updates four files via CVS and checks their contents using 'test_cmp', but it does so in a for loop iterating over the names of those four files. Now, the exit status of a for loop is the exit status of the last command executed in the loop, meaning that the test can't simply rely on the exit code of 'test_cmp' in the loop's body. Instead, the test works it around by relying on the stdout of 'test_cmp' being silent on success and showing the diff on failure, as it appends the stdout of all four 'test_cmp' invocations to a single file and checks that file's emptiness after the loop (with 'test -z "$(cat ...)"', no less; there was no 'test_must_be_empty' back then). Furthermore, the test redirects the stderr of those 'test_cmp' invocations to this file, too: while 'test_cmp' itself doesn't output anything to stderr, the invoked 'diff' or 'cmp' commands do send their error messages there, e.g. if they can't open a file because its name was misspelled. This also makes this test fail when the test script is run with '-x' tracing (and using a shell other than a Bash version supporting BASH_XTRACEFD), because 'test_cmp's stderr contains the trace of the 'diff' command executed inside the helper function, throwing off the subsequent emptiness check. Stop relying on 'test_cmp's output and instead run 'test_cmp a b || return 1' in the for loop in order to make 'test_cmp's error code fail the test. Furthermore, add the missing && after the cvs command to create a && chain in the loop's body. After this change t9400 passes with '-x', even when running with /bin/sh. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-08Merge branch 'ag/userdiff-go-funcname'Libravatar Junio C Hamano6-0/+26
"git diff" and friends learned funcname patterns for Go language source files. * ag/userdiff-go-funcname: userdiff: add built-in pattern for golang