summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
2018-11-21Merge branch 'js/rebase-i-autosquash-fix' into maintLibravatar Junio C Hamano1-0/+19
"git rebase -i" did not clear the state files correctly when a run of "squash/fixup" is aborted and then the user manually amended the commit instead, which has been corrected. * js/rebase-i-autosquash-fix: rebase -i: be careful to wrap up fixup/squash chains rebase -i --autosquash: demonstrate a problem skipping the last squash
2018-11-21Merge branch 'jk/trailer-fixes' into maintLibravatar Junio C Hamano4-0/+104
"git interpret-trailers" and its underlying machinery had a buggy code that attempted to ignore patch text after commit log message, which triggered in various codepaths that will always get the log message alone and never get such an input. * jk/trailer-fixes: append_signoff: use size_t for string offsets sequencer: ignore "---" divider when parsing trailers pretty, ref-filter: format %(trailers) with no_divider option interpret-trailers: allow suppressing "---" divider interpret-trailers: tighten check for "---" patch boundary trailer: pass process_trailer_opts to trailer_info_get() trailer: use size_t for iterating trailer list trailer: use size_t for string offsets
2018-09-27Sync with 2.18.1Libravatar Junio C Hamano2-0/+77
* maint-2.18: Git 2.18.1 Git 2.17.2 fsck: detect submodule paths starting with dash fsck: detect submodule urls starting with dash 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.17.2Libravatar Junio C Hamano2-0/+77
* maint-2.17: Git 2.17.2 fsck: detect submodule paths starting with dash fsck: detect submodule urls starting with dash 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-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-09-10Merge branch 'jn/submodule-core-worktree-revert'Libravatar Junio C Hamano2-8/+2
* jn/submodule-core-worktree-revert: Revert "Merge branch 'sb/submodule-core-worktree'"
2018-09-10Merge branch 'mk/http-backend-content-length'Libravatar Junio C Hamano1-0/+11
The earlier attempt barfed when given a CONTENT_LENGTH that is set to an empty string. RFC 3875 is fairly clear that in this case we should not read any message body, but we've been reading through to the EOF in previous versions (which did not even pay attention to the environment variable), so keep that behaviour for now in this late update. * mk/http-backend-content-length: http-backend: allow empty CONTENT_LENGTH
2018-09-07Revert "Merge branch 'sb/submodule-core-worktree'"Libravatar Jonathan Nieder2-8/+2
This reverts commit 7e25437d35a70791b345872af202eabfb3e1a8bc, reversing changes made to 00624d608cc69bd62801c93e74d1ea7a7ddd6598. v2.19.0-rc0~165^2~1 (submodule: ensure core.worktree is set after update, 2018-06-18) assumes an "absorbed" submodule layout, where the submodule's Git directory is in the superproject's .git/modules/ directory and .git in the submodule worktree is a .git file pointing there. In particular, it uses $GIT_DIR/modules/$name to find the submodule to find out whether it already has core.worktree set, and it uses connect_work_tree_and_git_dir if not, resulting in fatal: could not open sub/.git for writing The context behind that patch: v2.19.0-rc0~165^2~2 (submodule: unset core.worktree if no working tree is present, 2018-06-12) unsets core.worktree when running commands like "git checkout --recurse-submodules" to switch to a branch without the submodule. If a user then uses "git checkout --no-recurse-submodules" to switch back to a branch with the submodule and runs "git submodule update", this patch is needed to ensure that commands using the submodule directly are aware of the path to the worktree. It is late in the release cycle, so revert the whole 3-patch series. We can try again later for 2.20. Reported-by: Allan Sandfeld Jensen <allan.jensen@qt.io> Helped-by: Stefan Beller <sbeller@google.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-09-07http-backend: allow empty CONTENT_LENGTHLibravatar Max Kirillov1-0/+11
According to RFC3875, empty environment variable is equivalent to unset, and for CONTENT_LENGTH it should mean zero body to read. However, unset CONTENT_LENGTH is also used for chunked encoding to indicate reading until EOF. At least, the test "large fetch-pack requests can be split across POSTs" from t5551 starts faliing, if unset or empty CONTENT_LENGTH is treated as zero length body. So keep the existing behavior as much as possible. Add a test for the case. Reported-By: Jelmer Vernooij <jelmer@jelmer.uk> Signed-off-by: Max Kirillov <max@max630.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-09-04Merge branch 'es/chain-lint-more'Libravatar Junio C Hamano5-4/+18
The test linter code has learned that the end of here-doc mark "EOF" can be quoted in a double-quote pair, not just in a single-quote pair. * es/chain-lint-more: chainlint: match "quoted" here-doc tags
2018-09-04Merge branch 'ab/portable-more'Libravatar Junio C Hamano10-44/+53
Portability fix. * ab/portable-more: tests: fix non-portable iconv invocation tests: fix non-portable "${var:-"str"}" construct tests: fix and add lint for non-portable grep --file tests: fix version-specific portability issue in Perl JSON tests: use shorter labels in chainlint.sed for AIX sed tests: fix comment syntax in chainlint.sed for AIX sed tests: fix and add lint for non-portable seq tests: fix and add lint for non-portable head -c N
2018-09-04Merge branch 'en/directory-renames-nothanks'Libravatar Junio C Hamano1-1/+109
Recent addition of "directory rename" heuristics to the merge-recursive backend makes the command susceptible to false positives and false negatives. In the context of "git am -3", which does not know about surrounding unmodified paths and thus cannot inform the merge machinery about the full trees involved, this risk is particularly severe. As such, the heuristic is disabled for "git am -3" to keep the machinery "more stupid but predictable". * en/directory-renames-nothanks: am: avoid directory rename detection when calling recursive merge machinery merge-recursive: add ability to turn off directory rename detection t3401: add another directory rename testcase for rebase and am
2018-09-04Merge branch 'pw/rebase-i-author-script-fix'Libravatar Junio C Hamano1-3/+15
Recent "git rebase -i" update started to write bogusly formatted author-script, with a matching broken reading code. These are fixed. * pw/rebase-i-author-script-fix: sequencer: fix quoting in write_author_script sequencer: handle errors from read_author_ident()
2018-09-04rebase -i: be careful to wrap up fixup/squash chainsLibravatar Johannes Schindelin1-1/+1
When an interactive rebase was stopped at the end of a fixup/squash chain, the user might have edited the commit manually before continuing (with either `git rebase --skip` or `git rebase --continue`, it does not really matter which). We need to be very careful to wrap up the fixup/squash chain also in this scenario: otherwise the next fixup/squash chain would try to pick up where the previous one was left. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2018-09-04rebase -i --autosquash: demonstrate a problem skipping the last squashLibravatar Johannes Schindelin1-0/+19
The `git commit --squash` command can be used not only to amend commit messages and changes, but also to record notes for an upcoming rebase. For example, when the author information of a given commit is incorrect, a user might call `git commit --allow-empty -m "Fix author" --squash <commit>`, to remind them to fix that during the rebase. When the editor would pop up, the user would simply delete the commit message to abort the rebase at this stage, fix the author information, and continue with `git rebase --skip`. (This is a real-world example from the rebase of Git for Windows onto v2.19.0-rc1.) However, there is a bug in `git rebase` that will cause the squash message *not* to be forgotten in this case. It will therefore be reused in the next fixup/squash chain (if any). This patch adds a test case to demonstrate this breakage. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2018-08-30am: avoid directory rename detection when calling recursive merge machineryLibravatar Elijah Newren1-2/+2
Let's say you have the following three trees, where Base is from one commit behind either master or branch: Base : bar_v1, foo/{file1, file2, file3} branch: bar_v2, foo/{file1, file2}, goo/file3 master: bar_v3, foo/{file1, file2, file3} Using git-am (or am-based rebase) to apply the changes from branch onto master results in the following tree: Result: bar_merged, goo/{file1, file2, file3} This is not what users want; they did not rename foo/ -> goo/, they only renamed one file within that directory. The reason this happens is am constructs fake trees (via build_fake_ancestor()) of the following form: Base_bfa : bar_v1, foo/file3 branch_bfa: bar_v2, goo/file3 Combining these two trees with master's tree: master: bar_v3, foo/{file1, file2, file3}, You can see that merge_recursive_generic() would see branch_bfa as renaming foo/ -> goo/, and master as just adding both foo/file1 and foo/file2. As such, it ends up with goo/{file1, file2, file3} The core problem is that am does not have access to the original trees; it can only construct trees using the blobs involved in the patch. As such, it is not safe to perform directory rename detection within am -3. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-30t3401: add another directory rename testcase for rebase and amLibravatar Elijah Newren1-1/+109
Similar to commit 16346883ab ("t3401: add directory rename testcases for rebase and am", 2018-06-27), add another testcase for directory rename detection. This new testcase differs in that it showcases a situation where no directory rename was performed, but which some backends incorrectly detect. As with the other testcase, run this in conjunction with each of the types of rebases: git-rebase--interactive git-rebase--am git-rebase--merge and also use the same testcase for git am --3way Reported-by: Nikolay Kasyanov <corrmage@gmail.com> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-29chainlint: match "quoted" here-doc tagsLibravatar Eric Sunshine5-4/+18
A here-doc tag can be quoted ('EOF'/"EOF") or escaped (\EOF) to suppress interpolation within the body. chainlint recognizes single-quoted and escaped tags, but does not know about double-quoted tags. For completeness, teach it to recognize double-quoted tags, as well. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-29tests: fix non-portable iconv invocationLibravatar Ævar Arnfjörð Bjarmason1-1/+5
The iconv that comes with a FreeBSD 11.2-RELEASE-p2 box I have access to doesn't support the SHIFT-JIS encoding. Guard a test added in e92d62253 ("convert: add round trip check based on 'core.checkRoundtripEncoding'", 2018-04-15) first released with Git v2.18.0 with a prerequisite that checks for its availability. The iconv command is in POSIX, and we have numerous tests unconditionally relying on its ability to convert ASCII, UTF-8 and UTF-16, but unconditionally relying on the presence of more obscure encodings isn't portable. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-29tests: fix non-portable "${var:-"str"}" constructLibravatar Ævar Arnfjörð Bjarmason1-1/+1
On both AIX 7200-00-01-1543 and FreeBSD 11.2-RELEASE-p2 the "${var:-"str"}" syntax means something different than what it does under the bash or dash shells. Both will consider the start of the new unescaped quotes to be a new argument to test_expect_success, resulting in the following error: error: bug in the test script: 'git diff-tree initial # magic is (not' does not look like a prereq Fix this by removing the redundant quotes. There's no need for them, and the resulting code works under all the aforementioned shells. This fixes a regression in c2f1d3989 ("t4013: test new output from diff --abbrev --raw", 2017-12-03) first released with Git v2.16.0. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-27Merge branch 'sg/test-rebase-editor-fix'Libravatar Junio C Hamano1-3/+3
Test fix. * sg/test-rebase-editor-fix: t/lib-rebase.sh: support explicit 'pick' commands in 'fake_editor.sh'
2018-08-27Merge branch 'ab/test-must-be-empty-for-master'Libravatar Junio C Hamano1-1/+1
Test fixes. * ab/test-must-be-empty-for-master: t6018-rev-list-glob: fix 'empty stdin' test
2018-08-27Merge branch 'sg/t3420-autostash-fix'Libravatar Junio C Hamano1-4/+4
Test fixes. * sg/t3420-autostash-fix: t3420-rebase-autostash: don't try to grep non-existing files
2018-08-27Merge branch 'sg/t3903-missing-fix'Libravatar Junio C Hamano1-1/+1
Test fixes. * sg/t3903-missing-fix: t3903-stash: don't try to grep non-existing file
2018-08-27Merge branch 'sg/t7501-thinkofix'Libravatar Junio C Hamano1-1/+1
Test fixes. * sg/t7501-thinkofix: t7501-commit: drop silly command substitution
2018-08-27Merge branch 'sg/t0020-conversion-fix'Libravatar Junio C Hamano1-1/+1
Test fixes. * sg/t0020-conversion-fix: t0020-crlf: check the right file
2018-08-27Merge branch 'sg/t4051-fix'Libravatar Junio C Hamano1-1/+1
Test fixes. * sg/t4051-fix: t4051-diff-function-context: read the right file
2018-08-27Merge branch 'jk/use-compat-util-in-test-tool'Libravatar Junio C Hamano1-0/+2
Dev tool update. * jk/use-compat-util-in-test-tool: test-tool.h: include git-compat-util.h
2018-08-27Merge branch 'sg/test-must-be-empty'Libravatar Junio C Hamano77-344/+231
Test fixes. * sg/test-must-be-empty: tests: use 'test_must_be_empty' instead of 'test_cmp <empty> <out>' tests: use 'test_must_be_empty' instead of 'test_cmp /dev/null <out>' tests: use 'test_must_be_empty' instead of 'test ! -s' tests: use 'test_must_be_empty' instead of '! test -s'
2018-08-27Merge branch 'ep/worktree-quiet-option'Libravatar Junio C Hamano1-0/+5
"git worktree" command learned "--quiet" option to make it less verbose. * ep/worktree-quiet-option: worktree: add --quiet option
2018-08-27Merge branch 'sm/branch-sort-config'Libravatar Junio C Hamano1-0/+46
"git branch --list" learned to take the default sort order from the 'branch.sort' configuration variable, just like "git tag --list" pays attention to 'tag.sort'. * sm/branch-sort-config: branch: support configuring --sort via .gitconfig
2018-08-27tests: fix and add lint for non-portable grep --fileLibravatar Ævar Arnfjörð Bjarmason2-1/+2
The --file option to grep isn't in POSIX[1], but -f is[1]. Let's check for that in the future, and fix the portability regression in f237c8b6fe ("commit-graph: implement git-commit-graph write", 2018-04-02) that broke e.g. AIX. 1. http://pubs.opengroup.org/onlinepubs/009695399/utilities/grep.html Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-27tests: fix version-specific portability issue in Perl JSONLibravatar Ævar Arnfjörð Bjarmason1-0/+3
The test guarded by PERLJSON added in 75459410ed ("json_writer: new routines to create JSON data", 2018-07-13) assumed that a JSON boolean value like "true" or "false" would be represented as "1" or "0" in Perl. This behavior can't be relied upon, e.g. with JSON.pm 2.50 and JSON::PP. A JSON::PP::Boolean object will be represented as "true" or "false". To work around this let's check if we have any refs left after we check for hashes and arrays, assume those are JSON objects, and coerce them to a known boolean value. The behavior of this test still looks odd to me. Why implement our own ad-hoc encoder just for some one-off test, as opposed to say Perl's own Data::Dumper with Sortkeys et al? But with this change it works, so let's leave it be. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-27tests: use shorter labels in chainlint.sed for AIX sedLibravatar Ævar Arnfjörð Bjarmason1-28/+28
Improve the portability of chainlint by using shorter labels. On AIX sed will complain about: sed: 0602-417 The label :hereslurp is greater than eight characters This, in combination with the previous fix to this file makes GIT_TEST_CHAIN_LINT=1 (which is the default) working again on AIX without issues, and the "gmake check-chainlint" test also passes. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Acked-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-27tests: fix comment syntax in chainlint.sed for AIX sedLibravatar Ævar Arnfjörð Bjarmason1-2/+1
Change a comment in chainlint.sed to appease AIX sed, which would previously print this error: sed: # stash for later printing is not a recognized function 1. https://public-inbox.org/git/CAPig+cTTbU5HFMKgNyrxTp3+kcK46-Fn=4ZH6zDt1oQChAc3KA@mail.gmail.com/ Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Acked-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-27tests: fix and add lint for non-portable seqLibravatar Ævar Arnfjörð Bjarmason3-8/+9
The seq command is not in POSIX, and doesn't exist on e.g. OpenBSD. We've had the test_seq wrapper since d17cf5f3a3 ("tests: Introduce test_seq", 2012-08-04), but use of it keeps coming back, e.g. in the recently added "fetch negotiator" tests being added here. So let's also add a check to "make test-lint". The regex is aiming to capture the likes of $(seq ..) and "seq" as a stand-alone command, without capturing some existing cases where we e.g. have files called "seq", as \bseq\b would do. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-27tests: fix and add lint for non-portable head -c NLibravatar Ævar Arnfjörð Bjarmason3-3/+4
The "head -c BYTES" option is non-portable (not in POSIX[1]). Change such invocations to use the test_copy_bytes wrapper added in 48860819e8 ("t9300: factor out portable "head -c" replacement", 2016-06-30). This fixes a test added in 9d2e330b17 ("ewah_read_mmap: bounds-check mmap reads", 2018-06-14), which has been breaking t5310-pack-bitmaps.sh on OpenBSD since 2.18.0. The OpenBSD ports already have a similar workaround after their upgrade to 2.18.0[2]. I have not tested this on IRIX, but according to 4de0bbd898 ("t9300: use perl "head -c" clone in place of "dd bs=1 count=16000" kluge", 2010-12-13) this invocation would have broken things there too. Also, change a valgrind-specific codepath in test-lib.sh to use this wrapper. Given where valgrind runs I don't think this would ever become a portability issue in practice, but it's easier to just use the wrapper than introduce some exception for the "make test-lint" check being added here. 1. http://pubs.opengroup.org/onlinepubs/9699919799/utilities/head.html 2. https://github.com/openbsd/ports/commit/08d5d82eaefe5cf2f125ecc0c6a57df9cf91350c#diff-f7d3c4fabeed1691620d608f1534f5e5 Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-23sequencer: ignore "---" divider when parsing trailersLibravatar Jeff King1-0/+16
When the sequencer code appends a signoff or cherry-pick origin, it uses the default trailer-parsing options, which treat "---" as the end of the commit message. As a result, it may be fooled by a commit message that contains that string and fail to find the existing trailer block. Even more confusing, the actual append code does not know about "---", and always appends to the end of the string. This can lead to bizarre results. E.g., appending a signoff to a commit message like this: subject body --- these dashes confuse the parser! Signed-off-by: A results in output with a final block like: Signed-off-by: A Signed-off-by: A The parser thinks the final line of the message is "body", and ignores everything else, claiming there are no trailers. So we output an extra newline separator (wrong) and add a duplicate signoff (also wrong). Since we know we are feeding a pure commit message, we can simply tell the parser to ignore the "---" divider. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-23pretty, ref-filter: format %(trailers) with no_divider optionLibravatar Jeff King2-0/+46
In both of these cases we know that we are feeding the trailer-parsing code a pure commit message. We should tell it so, which avoids false positives for a commit message that contains a "---" line. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-23interpret-trailers: allow suppressing "---" dividerLibravatar Jeff King1-0/+20
Even with the newly-tightened "---" parser, it's still possible for a commit message to trigger a false positive if it contains something like "--- foo". If the caller knows that it has only a single commit message, it can now tell us with the "--no-divider" option, eliminating any false positives. If we were designing this from scratch, I'd probably make this the default. But we've advertised the "---" behavior in the documentation since interpret-trailers has existed. Since it's meant to be scripted, breaking that would be a bad idea. Note that the logic is in the underlying trailer.c code, which is used elsewhere. The default there will keep the current behavior, but many callers will benefit from setting this new option. That's left for future patches. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-23interpret-trailers: tighten check for "---" patch boundaryLibravatar Jeff King1-0/+22
The interpret-trailers command accepts not only raw commit messages, but it also can manipulate trailers in format-patch output. That means it must find the "---" boundary separating the commit message from the patch. However, it does so by looking for any line starting with "---", regardless of whether there is further content. This is overly lax compared to the parsing done in mailinfo.c's patchbreak(), and may cause false positives (e.g., t/perf output tables uses dashes; if you cut and paste them into your commit message, it fools the parser). We could try to reuse patchbreak() here, but it actually has several heuristics that are not of interest to us (e.g., matching "diff -" without a three-dash separator or even a CVS "Index:" line). We're not interested in taking in whatever random cruft people may send, but rather handling git-formatted patches. Note that the existing documentation was written in a loose way, so technically we are changing the behavior from what it said. But this should implement the original intent in a more accurate way. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-23t/lib-rebase.sh: support explicit 'pick' commands in 'fake_editor.sh'Libravatar SZEDER Gábor1-3/+3
The verbose output of the test 'reword without issues functions as intended' in 't3423-rebase-reword.sh', added in a9279c6785 (sequencer: do not squash 'reword' commits when we hit conflicts, 2018-06-19), contains the following error output: sed: -e expression #1, char 2: extra characters after command This error comes from within the 'fake-editor.sh' script created by 'lib-rebase.sh's set_fake_editor() function, and the root cause is the FAKE_LINES="pick 1 reword 2" variable in the test in question, in particular the "pick" word. 'fake-editor.sh' assumes 'pick' to be the default rebase command and doesn't support an explicit 'pick' command in FAKE_LINES. As a result, 'pick' will be used instead of a line number when assembling the following 'sed' script: sed -n picks/^pick/pick/p which triggers the aforementioned error. Luckily, this didn't affect the test's correctness: the erroring 'sed' command doesn't write anything to the todo script, and processing the rest of FAKE_LINES generates the desired todo script, as if that 'pick' command were not there at all. The minimal fix would be to remove the 'pick' word from FAKE_LINES, but that would leave us susceptible to similar issues in the future. Instead, teach the fake-editor script to recognize an explicit 'pick' command, which is still a fairly trivial change. In the future we might want to consider reinforcing this fake editor script with an &&-chain and stricter parsing of the FAKE_LINES variable (e.g. to error out when encountering unknown rebase commands or commands and line numbers in the wrong order). Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-22t3420-rebase-autostash: don't try to grep non-existing filesLibravatar SZEDER Gábor1-4/+4
Several tests in 't3420-rebase-autostash.sh' start various rebase processes that are expected to fail because of merge conflicts. These tests then run '! grep' to ensure that the autostash feature did its job, and the dirty contents of a file is gone. However, due to the test repo's history and the choice of upstream branch that file shouldn't exist in the conflicted state at all. Consequently, this 'grep' doesn't fail as expected, because it can't find the dirty content, but it fails because it can't open the file. Tighten this check by using 'test_path_is_missing' instead, thereby avoiding unexpected errors from 'grep' as well. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-22t3903-stash: don't try to grep non-existing fileLibravatar SZEDER Gábor1-1/+1
The test 'store updates stash ref and reflog' in 't3903-stash.sh' creates a stash from a new file, runs 'git reset --hard' to throw away any modifications to the work tree, and then runs '! grep' to ensure that the staged contents are gone. Since the file didn't exist before, it shouldn't exist after 'git reset' either. Consequently, this 'grep' doesn't fail as expected, because it can't find the staged content, but it fails because it can't open the file. Tighten this check by using 'test_path_is_missing' instead, thereby avoiding an unexpected error from 'grep' as well. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>