git-commit-vandalism/t/t6200-fmt-merge-msg.sh

705 lines
17 KiB
Bash
Raw Normal View History

#!/bin/sh
#
# Copyright (c) 2006, Junio C Hamano
#
test_description='fmt-merge-msg test'
GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main
tests: mark tests relying on the current default for `init.defaultBranch` In addition to the manual adjustment to let the `linux-gcc` CI job run the test suite with `master` and then with `main`, this patch makes sure that GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME is set in all test scripts that currently rely on the initial branch name being `master by default. To determine which test scripts to mark up, the first step was to force-set the default branch name to `master` in - all test scripts that contain the keyword `master`, - t4211, which expects `t/t4211/history.export` with a hard-coded ref to initialize the default branch, - t5560 because it sources `t/t556x_common` which uses `master`, - t8002 and t8012 because both source `t/annotate-tests.sh` which also uses `master`) This trick was performed by this command: $ sed -i '/^ *\. \.\/\(test-lib\|lib-\(bash\|cvs\|git-svn\)\|gitweb-lib\)\.sh$/i\ GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master\ export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME\ ' $(git grep -l master t/t[0-9]*.sh) \ t/t4211*.sh t/t5560*.sh t/t8002*.sh t/t8012*.sh After that, careful, manual inspection revealed that some of the test scripts containing the needle `master` do not actually rely on a specific default branch name: either they mention `master` only in a comment, or they initialize that branch specificially, or they do not actually refer to the current default branch. Therefore, the aforementioned modification was undone in those test scripts thusly: $ git checkout HEAD -- \ t/t0027-auto-crlf.sh t/t0060-path-utils.sh \ t/t1011-read-tree-sparse-checkout.sh \ t/t1305-config-include.sh t/t1309-early-config.sh \ t/t1402-check-ref-format.sh t/t1450-fsck.sh \ t/t2024-checkout-dwim.sh \ t/t2106-update-index-assume-unchanged.sh \ t/t3040-subprojects-basic.sh t/t3301-notes.sh \ t/t3308-notes-merge.sh t/t3423-rebase-reword.sh \ t/t3436-rebase-more-options.sh \ t/t4015-diff-whitespace.sh t/t4257-am-interactive.sh \ t/t5323-pack-redundant.sh t/t5401-update-hooks.sh \ t/t5511-refspec.sh t/t5526-fetch-submodules.sh \ t/t5529-push-errors.sh t/t5530-upload-pack-error.sh \ t/t5548-push-porcelain.sh \ t/t5552-skipping-fetch-negotiator.sh \ t/t5572-pull-submodule.sh t/t5608-clone-2gb.sh \ t/t5614-clone-submodules-shallow.sh \ t/t7508-status.sh t/t7606-merge-custom.sh \ t/t9302-fast-import-unpack-limit.sh We excluded one set of test scripts in these commands, though: the range of `git p4` tests. The reason? `git p4` stores the (foreign) remote branch in the branch called `p4/master`, which is obviously not the default branch. Manual analysis revealed that only five of these tests actually require a specific default branch name to pass; They were modified thusly: $ sed -i '/^ *\. \.\/lib-git-p4\.sh$/i\ GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master\ export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME\ ' t/t980[0167]*.sh t/t9811*.sh Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-19 00:44:19 +01:00
export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME
. ./test-lib.sh
t: increase test coverage of signature verification output There weren't any tests for unsuccessful signature verification of signed merge tags shown in 'git log'. There also weren't any tests for the GPG output from 'git fmt-merge-msg'. This was noticed while investigating a buggy refactor that slipped through the test suite; see commit 72b006f4bfd30b7c5037c163efaf279ab65bea9c. This commit adds signature verification tests to the 'log' and 'fmt-merge-msg' builtins. Thanks to Linus Torvalds for reporting and finding the (now reverted) commit that introduced the regression. Note that the "log --show-signature for merged tag with GPG failure" test case is really hacky. It relies on an implementation detail of verify_signed_buffer() -- namely, it assumes that the signature is written to a temporary file whose path is under TMPDIR. The rationale for that test case is to check whether the code path that yields the "No signature" message is reachable on failure. The functionality in log-tree.c that may show this message does some pre-parsing of a possible signature that prevents the GPG interface from being invoked if a signature is actually missing. And I haven't been able to construct a signature that both 1. satisfies that pre-processing, and 2. causes GPG to fail without any sort of output on stderr along the lines of "this is a bogus/corrupt/... signature" (the "No signature" message should only be shown if GPG produce no output). Signed-off-by: Hans Jerry Illikainen <hji@dyntopia.com> [jc: fixed missing test title noticed by Dscho] Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-04 12:48:03 +01:00
. "$TEST_DIRECTORY/lib-gpg.sh"
test_expect_success setup '
echo one >one &&
git add one &&
test_tick &&
git commit -m "Initial" &&
git clone . remote &&
echo uno >one &&
echo dos >two &&
git add two &&
test_tick &&
git commit -a -m "Second" &&
git checkout -b left &&
echo "c1" >one &&
test_tick &&
git commit -a -m "Common #1" &&
echo "c2" >one &&
test_tick &&
git commit -a -m "Common #2" &&
git branch right &&
echo "l3" >two &&
test_tick &&
GIT_COMMITTER_NAME="Another Committer" \
GIT_AUTHOR_NAME="Another Author" git commit -a -m "Left #3" &&
echo "l4" >two &&
test_tick &&
GIT_COMMITTER_NAME="Another Committer" \
GIT_AUTHOR_NAME="Another Author" git commit -a -m "Left #4" &&
echo "l5" >two &&
test_tick &&
GIT_COMMITTER_NAME="Another Committer" \
GIT_AUTHOR_NAME="Another Author" git commit -a -m "Left #5" &&
git tag tag-l5 &&
git checkout right &&
echo "r3" >three &&
git add three &&
test_tick &&
git commit -a -m "Right #3" &&
git tag tag-r3 &&
echo "r4" >three &&
test_tick &&
git commit -a -m "Right #4" &&
echo "r5" >three &&
test_tick &&
git commit -a -m "Right #5" &&
git checkout -b long &&
test_commit_bulk --start=0 --message=%s --filename=one 30 &&
git show-branch &&
apos="'\''"
'
t: increase test coverage of signature verification output There weren't any tests for unsuccessful signature verification of signed merge tags shown in 'git log'. There also weren't any tests for the GPG output from 'git fmt-merge-msg'. This was noticed while investigating a buggy refactor that slipped through the test suite; see commit 72b006f4bfd30b7c5037c163efaf279ab65bea9c. This commit adds signature verification tests to the 'log' and 'fmt-merge-msg' builtins. Thanks to Linus Torvalds for reporting and finding the (now reverted) commit that introduced the regression. Note that the "log --show-signature for merged tag with GPG failure" test case is really hacky. It relies on an implementation detail of verify_signed_buffer() -- namely, it assumes that the signature is written to a temporary file whose path is under TMPDIR. The rationale for that test case is to check whether the code path that yields the "No signature" message is reachable on failure. The functionality in log-tree.c that may show this message does some pre-parsing of a possible signature that prevents the GPG interface from being invoked if a signature is actually missing. And I haven't been able to construct a signature that both 1. satisfies that pre-processing, and 2. causes GPG to fail without any sort of output on stderr along the lines of "this is a bogus/corrupt/... signature" (the "No signature" message should only be shown if GPG produce no output). Signed-off-by: Hans Jerry Illikainen <hji@dyntopia.com> [jc: fixed missing test title noticed by Dscho] Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-04 12:48:03 +01:00
test_expect_success GPG 'set up a signed tag' '
git tag -s -m signed-tag-msg signed-good-tag left
'
test_expect_success GPGSSH 'created ssh signed commit and tag' '
test_config gpg.format ssh &&
git checkout -b signed-ssh &&
touch file &&
git add file &&
git commit -m "ssh signed" -S"${GPGSSH_KEY_PRIMARY}" &&
git tag -s -u"${GPGSSH_KEY_PRIMARY}" -m signed-ssh-tag-msg signed-good-ssh-tag left &&
git tag -s -u"${GPGSSH_KEY_UNTRUSTED}" -m signed-ssh-tag-msg-untrusted signed-untrusted-ssh-tag left
'
test_expect_success GPGSSH,GPGSSH_VERIFYTIME 'create signed tags with keys having defined lifetimes' '
test_when_finished "test_unconfig commit.gpgsign" &&
test_config gpg.format ssh &&
git checkout -b signed-expiry-ssh &&
touch file &&
git add file &&
echo expired >file && test_tick && git commit -a -m expired -S"${GPGSSH_KEY_EXPIRED}" &&
git tag -s -u "${GPGSSH_KEY_EXPIRED}" -m expired-signed expired-signed &&
echo notyetvalid >file && test_tick && git commit -a -m notyetvalid -S"${GPGSSH_KEY_NOTYETVALID}" &&
git tag -s -u "${GPGSSH_KEY_NOTYETVALID}" -m notyetvalid-signed notyetvalid-signed &&
echo timeboxedvalid >file && test_tick && git commit -a -m timeboxedvalid -S"${GPGSSH_KEY_TIMEBOXEDVALID}" &&
git tag -s -u "${GPGSSH_KEY_TIMEBOXEDVALID}" -m timeboxedvalid-signed timeboxedvalid-signed &&
echo timeboxedinvalid >file && test_tick && git commit -a -m timeboxedinvalid -S"${GPGSSH_KEY_TIMEBOXEDINVALID}" &&
git tag -s -u "${GPGSSH_KEY_TIMEBOXEDINVALID}" -m timeboxedinvalid-signed timeboxedinvalid-signed
'
test_expect_success 'message for merging local branch' '
echo "Merge branch ${apos}left${apos}" >expected &&
git checkout main &&
git fetch . left &&
git fmt-merge-msg <.git/FETCH_HEAD >actual &&
test_cmp expected actual
'
t: increase test coverage of signature verification output There weren't any tests for unsuccessful signature verification of signed merge tags shown in 'git log'. There also weren't any tests for the GPG output from 'git fmt-merge-msg'. This was noticed while investigating a buggy refactor that slipped through the test suite; see commit 72b006f4bfd30b7c5037c163efaf279ab65bea9c. This commit adds signature verification tests to the 'log' and 'fmt-merge-msg' builtins. Thanks to Linus Torvalds for reporting and finding the (now reverted) commit that introduced the regression. Note that the "log --show-signature for merged tag with GPG failure" test case is really hacky. It relies on an implementation detail of verify_signed_buffer() -- namely, it assumes that the signature is written to a temporary file whose path is under TMPDIR. The rationale for that test case is to check whether the code path that yields the "No signature" message is reachable on failure. The functionality in log-tree.c that may show this message does some pre-parsing of a possible signature that prevents the GPG interface from being invoked if a signature is actually missing. And I haven't been able to construct a signature that both 1. satisfies that pre-processing, and 2. causes GPG to fail without any sort of output on stderr along the lines of "this is a bogus/corrupt/... signature" (the "No signature" message should only be shown if GPG produce no output). Signed-off-by: Hans Jerry Illikainen <hji@dyntopia.com> [jc: fixed missing test title noticed by Dscho] Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-04 12:48:03 +01:00
test_expect_success GPG 'message for merging local tag signed by good key' '
git checkout main &&
t: increase test coverage of signature verification output There weren't any tests for unsuccessful signature verification of signed merge tags shown in 'git log'. There also weren't any tests for the GPG output from 'git fmt-merge-msg'. This was noticed while investigating a buggy refactor that slipped through the test suite; see commit 72b006f4bfd30b7c5037c163efaf279ab65bea9c. This commit adds signature verification tests to the 'log' and 'fmt-merge-msg' builtins. Thanks to Linus Torvalds for reporting and finding the (now reverted) commit that introduced the regression. Note that the "log --show-signature for merged tag with GPG failure" test case is really hacky. It relies on an implementation detail of verify_signed_buffer() -- namely, it assumes that the signature is written to a temporary file whose path is under TMPDIR. The rationale for that test case is to check whether the code path that yields the "No signature" message is reachable on failure. The functionality in log-tree.c that may show this message does some pre-parsing of a possible signature that prevents the GPG interface from being invoked if a signature is actually missing. And I haven't been able to construct a signature that both 1. satisfies that pre-processing, and 2. causes GPG to fail without any sort of output on stderr along the lines of "this is a bogus/corrupt/... signature" (the "No signature" message should only be shown if GPG produce no output). Signed-off-by: Hans Jerry Illikainen <hji@dyntopia.com> [jc: fixed missing test title noticed by Dscho] Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-04 12:48:03 +01:00
git fetch . signed-good-tag &&
git fmt-merge-msg <.git/FETCH_HEAD >actual &&
t: increase test coverage of signature verification output There weren't any tests for unsuccessful signature verification of signed merge tags shown in 'git log'. There also weren't any tests for the GPG output from 'git fmt-merge-msg'. This was noticed while investigating a buggy refactor that slipped through the test suite; see commit 72b006f4bfd30b7c5037c163efaf279ab65bea9c. This commit adds signature verification tests to the 'log' and 'fmt-merge-msg' builtins. Thanks to Linus Torvalds for reporting and finding the (now reverted) commit that introduced the regression. Note that the "log --show-signature for merged tag with GPG failure" test case is really hacky. It relies on an implementation detail of verify_signed_buffer() -- namely, it assumes that the signature is written to a temporary file whose path is under TMPDIR. The rationale for that test case is to check whether the code path that yields the "No signature" message is reachable on failure. The functionality in log-tree.c that may show this message does some pre-parsing of a possible signature that prevents the GPG interface from being invoked if a signature is actually missing. And I haven't been able to construct a signature that both 1. satisfies that pre-processing, and 2. causes GPG to fail without any sort of output on stderr along the lines of "this is a bogus/corrupt/... signature" (the "No signature" message should only be shown if GPG produce no output). Signed-off-by: Hans Jerry Illikainen <hji@dyntopia.com> [jc: fixed missing test title noticed by Dscho] Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-04 12:48:03 +01:00
grep "^Merge tag ${apos}signed-good-tag${apos}" actual &&
fmt-merge-msg: prevent use-after-free with signed tags When merging a signed tag, fmt_merge_msg_sigs() is responsible for populating the body of the merge message with the names of the signed tags, their signatures, and the validity of those signatures. In 02769437e1 (ssh signing: use sigc struct to pass payload, 2021-12-09), check_signature() was taught to pass the object payload via the sigc struct instead of passing the payload buffer separately. In effect, 02769437e1 causes buf, and sigc.payload to point at the same region in memory. This causes a problem for fmt_tag_signature(), which wants to read from this location, since it is freed beforehand by signature_check_clear() (which frees it via sigc's `payload` member). That makes the subsequent use in fmt_tag_signature() a use-after-free. As a result, merge messages did not contain the body of any signed tags. Luckily, they tend not to contain garbage, either, since the result of strstr()-ing the object buffer in fmt_tag_signature() is guarded: const char *tag_body = strstr(buf, "\n\n"); if (tag_body) { tag_body += 2; strbuf_add(tagbuf, tag_body, buf + len - tag_body); } Unfortunately, the tests in t6200 did not catch this at the time because they do not search for the body of signed tags in fmt-merge-msg's output. Resolve this by waiting to call signature_check_clear() until after its contents can be safely discarded. Harden ourselves against any future regressions in this area by making sure we can find signed tag messages in the output of fmt-merge-msg, too. Reported-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-10 22:19:06 +01:00
grep "^signed-tag-msg" actual &&
t: increase test coverage of signature verification output There weren't any tests for unsuccessful signature verification of signed merge tags shown in 'git log'. There also weren't any tests for the GPG output from 'git fmt-merge-msg'. This was noticed while investigating a buggy refactor that slipped through the test suite; see commit 72b006f4bfd30b7c5037c163efaf279ab65bea9c. This commit adds signature verification tests to the 'log' and 'fmt-merge-msg' builtins. Thanks to Linus Torvalds for reporting and finding the (now reverted) commit that introduced the regression. Note that the "log --show-signature for merged tag with GPG failure" test case is really hacky. It relies on an implementation detail of verify_signed_buffer() -- namely, it assumes that the signature is written to a temporary file whose path is under TMPDIR. The rationale for that test case is to check whether the code path that yields the "No signature" message is reachable on failure. The functionality in log-tree.c that may show this message does some pre-parsing of a possible signature that prevents the GPG interface from being invoked if a signature is actually missing. And I haven't been able to construct a signature that both 1. satisfies that pre-processing, and 2. causes GPG to fail without any sort of output on stderr along the lines of "this is a bogus/corrupt/... signature" (the "No signature" message should only be shown if GPG produce no output). Signed-off-by: Hans Jerry Illikainen <hji@dyntopia.com> [jc: fixed missing test title noticed by Dscho] Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-04 12:48:03 +01:00
grep "^# gpg: Signature made" actual &&
grep "^# gpg: Good signature from" actual
'
test_expect_success GPG 'message for merging local tag signed by unknown key' '
git checkout main &&
t: increase test coverage of signature verification output There weren't any tests for unsuccessful signature verification of signed merge tags shown in 'git log'. There also weren't any tests for the GPG output from 'git fmt-merge-msg'. This was noticed while investigating a buggy refactor that slipped through the test suite; see commit 72b006f4bfd30b7c5037c163efaf279ab65bea9c. This commit adds signature verification tests to the 'log' and 'fmt-merge-msg' builtins. Thanks to Linus Torvalds for reporting and finding the (now reverted) commit that introduced the regression. Note that the "log --show-signature for merged tag with GPG failure" test case is really hacky. It relies on an implementation detail of verify_signed_buffer() -- namely, it assumes that the signature is written to a temporary file whose path is under TMPDIR. The rationale for that test case is to check whether the code path that yields the "No signature" message is reachable on failure. The functionality in log-tree.c that may show this message does some pre-parsing of a possible signature that prevents the GPG interface from being invoked if a signature is actually missing. And I haven't been able to construct a signature that both 1. satisfies that pre-processing, and 2. causes GPG to fail without any sort of output on stderr along the lines of "this is a bogus/corrupt/... signature" (the "No signature" message should only be shown if GPG produce no output). Signed-off-by: Hans Jerry Illikainen <hji@dyntopia.com> [jc: fixed missing test title noticed by Dscho] Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-04 12:48:03 +01:00
git fetch . signed-good-tag &&
GNUPGHOME=. git fmt-merge-msg <.git/FETCH_HEAD >actual &&
t: increase test coverage of signature verification output There weren't any tests for unsuccessful signature verification of signed merge tags shown in 'git log'. There also weren't any tests for the GPG output from 'git fmt-merge-msg'. This was noticed while investigating a buggy refactor that slipped through the test suite; see commit 72b006f4bfd30b7c5037c163efaf279ab65bea9c. This commit adds signature verification tests to the 'log' and 'fmt-merge-msg' builtins. Thanks to Linus Torvalds for reporting and finding the (now reverted) commit that introduced the regression. Note that the "log --show-signature for merged tag with GPG failure" test case is really hacky. It relies on an implementation detail of verify_signed_buffer() -- namely, it assumes that the signature is written to a temporary file whose path is under TMPDIR. The rationale for that test case is to check whether the code path that yields the "No signature" message is reachable on failure. The functionality in log-tree.c that may show this message does some pre-parsing of a possible signature that prevents the GPG interface from being invoked if a signature is actually missing. And I haven't been able to construct a signature that both 1. satisfies that pre-processing, and 2. causes GPG to fail without any sort of output on stderr along the lines of "this is a bogus/corrupt/... signature" (the "No signature" message should only be shown if GPG produce no output). Signed-off-by: Hans Jerry Illikainen <hji@dyntopia.com> [jc: fixed missing test title noticed by Dscho] Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-04 12:48:03 +01:00
grep "^Merge tag ${apos}signed-good-tag${apos}" actual &&
fmt-merge-msg: prevent use-after-free with signed tags When merging a signed tag, fmt_merge_msg_sigs() is responsible for populating the body of the merge message with the names of the signed tags, their signatures, and the validity of those signatures. In 02769437e1 (ssh signing: use sigc struct to pass payload, 2021-12-09), check_signature() was taught to pass the object payload via the sigc struct instead of passing the payload buffer separately. In effect, 02769437e1 causes buf, and sigc.payload to point at the same region in memory. This causes a problem for fmt_tag_signature(), which wants to read from this location, since it is freed beforehand by signature_check_clear() (which frees it via sigc's `payload` member). That makes the subsequent use in fmt_tag_signature() a use-after-free. As a result, merge messages did not contain the body of any signed tags. Luckily, they tend not to contain garbage, either, since the result of strstr()-ing the object buffer in fmt_tag_signature() is guarded: const char *tag_body = strstr(buf, "\n\n"); if (tag_body) { tag_body += 2; strbuf_add(tagbuf, tag_body, buf + len - tag_body); } Unfortunately, the tests in t6200 did not catch this at the time because they do not search for the body of signed tags in fmt-merge-msg's output. Resolve this by waiting to call signature_check_clear() until after its contents can be safely discarded. Harden ourselves against any future regressions in this area by making sure we can find signed tag messages in the output of fmt-merge-msg, too. Reported-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-10 22:19:06 +01:00
grep "^signed-tag-msg" actual &&
t: increase test coverage of signature verification output There weren't any tests for unsuccessful signature verification of signed merge tags shown in 'git log'. There also weren't any tests for the GPG output from 'git fmt-merge-msg'. This was noticed while investigating a buggy refactor that slipped through the test suite; see commit 72b006f4bfd30b7c5037c163efaf279ab65bea9c. This commit adds signature verification tests to the 'log' and 'fmt-merge-msg' builtins. Thanks to Linus Torvalds for reporting and finding the (now reverted) commit that introduced the regression. Note that the "log --show-signature for merged tag with GPG failure" test case is really hacky. It relies on an implementation detail of verify_signed_buffer() -- namely, it assumes that the signature is written to a temporary file whose path is under TMPDIR. The rationale for that test case is to check whether the code path that yields the "No signature" message is reachable on failure. The functionality in log-tree.c that may show this message does some pre-parsing of a possible signature that prevents the GPG interface from being invoked if a signature is actually missing. And I haven't been able to construct a signature that both 1. satisfies that pre-processing, and 2. causes GPG to fail without any sort of output on stderr along the lines of "this is a bogus/corrupt/... signature" (the "No signature" message should only be shown if GPG produce no output). Signed-off-by: Hans Jerry Illikainen <hji@dyntopia.com> [jc: fixed missing test title noticed by Dscho] Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-04 12:48:03 +01:00
grep "^# gpg: Signature made" actual &&
grep -E "^# gpg: Can${apos}t check signature: (public key not found|No public key)" actual
t: increase test coverage of signature verification output There weren't any tests for unsuccessful signature verification of signed merge tags shown in 'git log'. There also weren't any tests for the GPG output from 'git fmt-merge-msg'. This was noticed while investigating a buggy refactor that slipped through the test suite; see commit 72b006f4bfd30b7c5037c163efaf279ab65bea9c. This commit adds signature verification tests to the 'log' and 'fmt-merge-msg' builtins. Thanks to Linus Torvalds for reporting and finding the (now reverted) commit that introduced the regression. Note that the "log --show-signature for merged tag with GPG failure" test case is really hacky. It relies on an implementation detail of verify_signed_buffer() -- namely, it assumes that the signature is written to a temporary file whose path is under TMPDIR. The rationale for that test case is to check whether the code path that yields the "No signature" message is reachable on failure. The functionality in log-tree.c that may show this message does some pre-parsing of a possible signature that prevents the GPG interface from being invoked if a signature is actually missing. And I haven't been able to construct a signature that both 1. satisfies that pre-processing, and 2. causes GPG to fail without any sort of output on stderr along the lines of "this is a bogus/corrupt/... signature" (the "No signature" message should only be shown if GPG produce no output). Signed-off-by: Hans Jerry Illikainen <hji@dyntopia.com> [jc: fixed missing test title noticed by Dscho] Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-04 12:48:03 +01:00
'
test_expect_success GPGSSH 'message for merging local tag signed by good ssh key' '
test_config gpg.ssh.allowedSignersFile "${GPGSSH_ALLOWED_SIGNERS}" &&
git checkout main &&
git fetch . signed-good-ssh-tag &&
git fmt-merge-msg <.git/FETCH_HEAD >actual &&
grep "^Merge tag ${apos}signed-good-ssh-tag${apos}" actual &&
fmt-merge-msg: prevent use-after-free with signed tags When merging a signed tag, fmt_merge_msg_sigs() is responsible for populating the body of the merge message with the names of the signed tags, their signatures, and the validity of those signatures. In 02769437e1 (ssh signing: use sigc struct to pass payload, 2021-12-09), check_signature() was taught to pass the object payload via the sigc struct instead of passing the payload buffer separately. In effect, 02769437e1 causes buf, and sigc.payload to point at the same region in memory. This causes a problem for fmt_tag_signature(), which wants to read from this location, since it is freed beforehand by signature_check_clear() (which frees it via sigc's `payload` member). That makes the subsequent use in fmt_tag_signature() a use-after-free. As a result, merge messages did not contain the body of any signed tags. Luckily, they tend not to contain garbage, either, since the result of strstr()-ing the object buffer in fmt_tag_signature() is guarded: const char *tag_body = strstr(buf, "\n\n"); if (tag_body) { tag_body += 2; strbuf_add(tagbuf, tag_body, buf + len - tag_body); } Unfortunately, the tests in t6200 did not catch this at the time because they do not search for the body of signed tags in fmt-merge-msg's output. Resolve this by waiting to call signature_check_clear() until after its contents can be safely discarded. Harden ourselves against any future regressions in this area by making sure we can find signed tag messages in the output of fmt-merge-msg, too. Reported-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-10 22:19:06 +01:00
grep "^signed-ssh-tag-msg" actual &&
grep "${GPGSSH_GOOD_SIGNATURE_TRUSTED}" actual &&
! grep "${GPGSSH_BAD_SIGNATURE}" actual
'
test_expect_success GPGSSH 'message for merging local tag signed by unknown ssh key' '
test_config gpg.ssh.allowedSignersFile "${GPGSSH_ALLOWED_SIGNERS}" &&
git checkout main &&
git fetch . signed-untrusted-ssh-tag &&
git fmt-merge-msg <.git/FETCH_HEAD >actual &&
grep "^Merge tag ${apos}signed-untrusted-ssh-tag${apos}" actual &&
fmt-merge-msg: prevent use-after-free with signed tags When merging a signed tag, fmt_merge_msg_sigs() is responsible for populating the body of the merge message with the names of the signed tags, their signatures, and the validity of those signatures. In 02769437e1 (ssh signing: use sigc struct to pass payload, 2021-12-09), check_signature() was taught to pass the object payload via the sigc struct instead of passing the payload buffer separately. In effect, 02769437e1 causes buf, and sigc.payload to point at the same region in memory. This causes a problem for fmt_tag_signature(), which wants to read from this location, since it is freed beforehand by signature_check_clear() (which frees it via sigc's `payload` member). That makes the subsequent use in fmt_tag_signature() a use-after-free. As a result, merge messages did not contain the body of any signed tags. Luckily, they tend not to contain garbage, either, since the result of strstr()-ing the object buffer in fmt_tag_signature() is guarded: const char *tag_body = strstr(buf, "\n\n"); if (tag_body) { tag_body += 2; strbuf_add(tagbuf, tag_body, buf + len - tag_body); } Unfortunately, the tests in t6200 did not catch this at the time because they do not search for the body of signed tags in fmt-merge-msg's output. Resolve this by waiting to call signature_check_clear() until after its contents can be safely discarded. Harden ourselves against any future regressions in this area by making sure we can find signed tag messages in the output of fmt-merge-msg, too. Reported-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-10 22:19:06 +01:00
grep "^signed-ssh-tag-msg-untrusted" actual &&
grep "${GPGSSH_GOOD_SIGNATURE_UNTRUSTED}" actual &&
! grep "${GPGSSH_BAD_SIGNATURE}" actual &&
grep "${GPGSSH_KEY_NOT_TRUSTED}" actual
'
test_expect_success GPGSSH,GPGSSH_VERIFYTIME 'message for merging local tag signed by expired ssh key' '
test_config gpg.ssh.allowedSignersFile "${GPGSSH_ALLOWED_SIGNERS}" &&
git checkout main &&
git fetch . expired-signed &&
git fmt-merge-msg <.git/FETCH_HEAD >actual &&
grep "^Merge tag ${apos}expired-signed${apos}" actual &&
fmt-merge-msg: prevent use-after-free with signed tags When merging a signed tag, fmt_merge_msg_sigs() is responsible for populating the body of the merge message with the names of the signed tags, their signatures, and the validity of those signatures. In 02769437e1 (ssh signing: use sigc struct to pass payload, 2021-12-09), check_signature() was taught to pass the object payload via the sigc struct instead of passing the payload buffer separately. In effect, 02769437e1 causes buf, and sigc.payload to point at the same region in memory. This causes a problem for fmt_tag_signature(), which wants to read from this location, since it is freed beforehand by signature_check_clear() (which frees it via sigc's `payload` member). That makes the subsequent use in fmt_tag_signature() a use-after-free. As a result, merge messages did not contain the body of any signed tags. Luckily, they tend not to contain garbage, either, since the result of strstr()-ing the object buffer in fmt_tag_signature() is guarded: const char *tag_body = strstr(buf, "\n\n"); if (tag_body) { tag_body += 2; strbuf_add(tagbuf, tag_body, buf + len - tag_body); } Unfortunately, the tests in t6200 did not catch this at the time because they do not search for the body of signed tags in fmt-merge-msg's output. Resolve this by waiting to call signature_check_clear() until after its contents can be safely discarded. Harden ourselves against any future regressions in this area by making sure we can find signed tag messages in the output of fmt-merge-msg, too. Reported-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-10 22:19:06 +01:00
grep "^expired-signed" actual &&
! grep "${GPGSSH_GOOD_SIGNATURE_TRUSTED}" actual
'
test_expect_success GPGSSH,GPGSSH_VERIFYTIME 'message for merging local tag signed by not yet valid ssh key' '
test_config gpg.ssh.allowedSignersFile "${GPGSSH_ALLOWED_SIGNERS}" &&
git checkout main &&
git fetch . notyetvalid-signed &&
git fmt-merge-msg <.git/FETCH_HEAD >actual &&
grep "^Merge tag ${apos}notyetvalid-signed${apos}" actual &&
fmt-merge-msg: prevent use-after-free with signed tags When merging a signed tag, fmt_merge_msg_sigs() is responsible for populating the body of the merge message with the names of the signed tags, their signatures, and the validity of those signatures. In 02769437e1 (ssh signing: use sigc struct to pass payload, 2021-12-09), check_signature() was taught to pass the object payload via the sigc struct instead of passing the payload buffer separately. In effect, 02769437e1 causes buf, and sigc.payload to point at the same region in memory. This causes a problem for fmt_tag_signature(), which wants to read from this location, since it is freed beforehand by signature_check_clear() (which frees it via sigc's `payload` member). That makes the subsequent use in fmt_tag_signature() a use-after-free. As a result, merge messages did not contain the body of any signed tags. Luckily, they tend not to contain garbage, either, since the result of strstr()-ing the object buffer in fmt_tag_signature() is guarded: const char *tag_body = strstr(buf, "\n\n"); if (tag_body) { tag_body += 2; strbuf_add(tagbuf, tag_body, buf + len - tag_body); } Unfortunately, the tests in t6200 did not catch this at the time because they do not search for the body of signed tags in fmt-merge-msg's output. Resolve this by waiting to call signature_check_clear() until after its contents can be safely discarded. Harden ourselves against any future regressions in this area by making sure we can find signed tag messages in the output of fmt-merge-msg, too. Reported-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-10 22:19:06 +01:00
grep "^notyetvalid-signed" actual &&
! grep "${GPGSSH_GOOD_SIGNATURE_TRUSTED}" actual
'
test_expect_success GPGSSH,GPGSSH_VERIFYTIME 'message for merging local tag signed by valid timeboxed ssh key' '
test_config gpg.ssh.allowedSignersFile "${GPGSSH_ALLOWED_SIGNERS}" &&
git checkout main &&
git fetch . timeboxedvalid-signed &&
git fmt-merge-msg <.git/FETCH_HEAD >actual &&
grep "^Merge tag ${apos}timeboxedvalid-signed${apos}" actual &&
fmt-merge-msg: prevent use-after-free with signed tags When merging a signed tag, fmt_merge_msg_sigs() is responsible for populating the body of the merge message with the names of the signed tags, their signatures, and the validity of those signatures. In 02769437e1 (ssh signing: use sigc struct to pass payload, 2021-12-09), check_signature() was taught to pass the object payload via the sigc struct instead of passing the payload buffer separately. In effect, 02769437e1 causes buf, and sigc.payload to point at the same region in memory. This causes a problem for fmt_tag_signature(), which wants to read from this location, since it is freed beforehand by signature_check_clear() (which frees it via sigc's `payload` member). That makes the subsequent use in fmt_tag_signature() a use-after-free. As a result, merge messages did not contain the body of any signed tags. Luckily, they tend not to contain garbage, either, since the result of strstr()-ing the object buffer in fmt_tag_signature() is guarded: const char *tag_body = strstr(buf, "\n\n"); if (tag_body) { tag_body += 2; strbuf_add(tagbuf, tag_body, buf + len - tag_body); } Unfortunately, the tests in t6200 did not catch this at the time because they do not search for the body of signed tags in fmt-merge-msg's output. Resolve this by waiting to call signature_check_clear() until after its contents can be safely discarded. Harden ourselves against any future regressions in this area by making sure we can find signed tag messages in the output of fmt-merge-msg, too. Reported-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-10 22:19:06 +01:00
grep "^timeboxedvalid-signed" actual &&
grep "${GPGSSH_GOOD_SIGNATURE_TRUSTED}" actual &&
! grep "${GPGSSH_BAD_SIGNATURE}" actual
'
test_expect_success GPGSSH,GPGSSH_VERIFYTIME 'message for merging local tag signed by invalid timeboxed ssh key' '
test_config gpg.ssh.allowedSignersFile "${GPGSSH_ALLOWED_SIGNERS}" &&
git checkout main &&
git fetch . timeboxedinvalid-signed &&
git fmt-merge-msg <.git/FETCH_HEAD >actual &&
grep "^Merge tag ${apos}timeboxedinvalid-signed${apos}" actual &&
fmt-merge-msg: prevent use-after-free with signed tags When merging a signed tag, fmt_merge_msg_sigs() is responsible for populating the body of the merge message with the names of the signed tags, their signatures, and the validity of those signatures. In 02769437e1 (ssh signing: use sigc struct to pass payload, 2021-12-09), check_signature() was taught to pass the object payload via the sigc struct instead of passing the payload buffer separately. In effect, 02769437e1 causes buf, and sigc.payload to point at the same region in memory. This causes a problem for fmt_tag_signature(), which wants to read from this location, since it is freed beforehand by signature_check_clear() (which frees it via sigc's `payload` member). That makes the subsequent use in fmt_tag_signature() a use-after-free. As a result, merge messages did not contain the body of any signed tags. Luckily, they tend not to contain garbage, either, since the result of strstr()-ing the object buffer in fmt_tag_signature() is guarded: const char *tag_body = strstr(buf, "\n\n"); if (tag_body) { tag_body += 2; strbuf_add(tagbuf, tag_body, buf + len - tag_body); } Unfortunately, the tests in t6200 did not catch this at the time because they do not search for the body of signed tags in fmt-merge-msg's output. Resolve this by waiting to call signature_check_clear() until after its contents can be safely discarded. Harden ourselves against any future regressions in this area by making sure we can find signed tag messages in the output of fmt-merge-msg, too. Reported-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-10 22:19:06 +01:00
grep "^timeboxedinvalid-signed" actual &&
! grep "${GPGSSH_GOOD_SIGNATURE_TRUSTED}" actual
'
test_expect_success 'message for merging external branch' '
echo "Merge branch ${apos}left${apos} of $(pwd)" >expected &&
git checkout main &&
git fetch "$(pwd)" left &&
git fmt-merge-msg <.git/FETCH_HEAD >actual &&
test_cmp expected actual
'
test_expect_success '[merge] summary/log configuration' '
cat >expected <<-EOF &&
Merge branch ${apos}left${apos}
# By Another Author (3) and A U Thor (2)
# Via Another Committer
* left:
Left #5
Left #4
Left #3
Common #2
Common #1
EOF
test_config merge.log true &&
test_unconfig merge.summary &&
git checkout main &&
test_tick &&
git fetch . left &&
git fmt-merge-msg <.git/FETCH_HEAD >actual1 &&
test_unconfig merge.log &&
test_config merge.summary true &&
git checkout main &&
test_tick &&
git fetch . left &&
git fmt-merge-msg <.git/FETCH_HEAD >actual2 &&
test_cmp expected actual1 &&
test_cmp expected actual2
'
test_expect_success 'setup FETCH_HEAD' '
git checkout main &&
test_tick &&
git fetch . left
'
test_expect_success 'merge.log=3 limits shortlog length' '
cat >expected <<-EOF &&
Merge branch ${apos}left${apos}
# By Another Author (3) and A U Thor (2)
# Via Another Committer
* left: (5 commits)
Left #5
Left #4
Left #3
...
EOF
git -c merge.log=3 fmt-merge-msg <.git/FETCH_HEAD >actual &&
test_cmp expected actual
'
test_expect_success 'merge.log=5 shows all 5 commits' '
cat >expected <<-EOF &&
Merge branch ${apos}left${apos}
# By Another Author (3) and A U Thor (2)
# Via Another Committer
* left:
Left #5
Left #4
Left #3
Common #2
Common #1
EOF
git -c merge.log=5 fmt-merge-msg <.git/FETCH_HEAD >actual &&
test_cmp expected actual
'
test_expect_success '--log=5 with custom comment character' '
cat >expected <<-EOF &&
Merge branch ${apos}left${apos}
x By Another Author (3) and A U Thor (2)
x Via Another Committer
* left:
Left #5
Left #4
Left #3
Common #2
Common #1
EOF
git -c core.commentchar="x" fmt-merge-msg --log=5 <.git/FETCH_HEAD >actual &&
test_cmp expected actual
'
test_expect_success 'merge.log=0 disables shortlog' '
echo "Merge branch ${apos}left${apos}" >expected &&
git -c merge.log=0 fmt-merge-msg <.git/FETCH_HEAD >actual &&
test_cmp expected actual
'
test_expect_success '--log=3 limits shortlog length' '
cat >expected <<-EOF &&
Merge branch ${apos}left${apos}
# By Another Author (3) and A U Thor (2)
# Via Another Committer
* left: (5 commits)
Left #5
Left #4
Left #3
...
EOF
git fmt-merge-msg --log=3 <.git/FETCH_HEAD >actual &&
test_cmp expected actual
'
test_expect_success '--log=5 shows all 5 commits' '
cat >expected <<-EOF &&
Merge branch ${apos}left${apos}
# By Another Author (3) and A U Thor (2)
# Via Another Committer
* left:
Left #5
Left #4
Left #3
Common #2
Common #1
EOF
git fmt-merge-msg --log=5 <.git/FETCH_HEAD >actual &&
test_cmp expected actual
'
test_expect_success '--no-log disables shortlog' '
echo "Merge branch ${apos}left${apos}" >expected &&
git fmt-merge-msg --no-log <.git/FETCH_HEAD >actual &&
test_cmp expected actual
'
test_expect_success '--log=0 disables shortlog' '
echo "Merge branch ${apos}left${apos}" >expected &&
git fmt-merge-msg --no-log <.git/FETCH_HEAD >actual &&
test_cmp expected actual
'
test_expect_success 'fmt-merge-msg -m' '
echo "Sync with left" >expected &&
cat >expected.log <<-EOF &&
Sync with left
# By Another Author (3) and A U Thor (2)
# Via Another Committer
* ${apos}left${apos} of $(pwd):
Left #5
Left #4
Left #3
Common #2
Common #1
EOF
test_unconfig merge.log &&
test_unconfig merge.summary &&
git checkout main &&
git fetch "$(pwd)" left &&
git fmt-merge-msg -m "Sync with left" <.git/FETCH_HEAD >actual &&
git fmt-merge-msg --log -m "Sync with left" \
<.git/FETCH_HEAD >actual.log &&
test_config merge.log true &&
git fmt-merge-msg -m "Sync with left" \
<.git/FETCH_HEAD >actual.log-config &&
git fmt-merge-msg --no-log -m "Sync with left" \
<.git/FETCH_HEAD >actual.nolog &&
test_cmp expected actual &&
test_cmp expected.log actual.log &&
test_cmp expected.log actual.log-config &&
test_cmp expected actual.nolog
'
test_expect_success 'setup: expected shortlog for two branches' '
cat >expected <<-EOF
Merge branches ${apos}left${apos} and ${apos}right${apos}
# By Another Author (3) and A U Thor (2)
# Via Another Committer
* left:
Left #5
Left #4
Left #3
Common #2
Common #1
* right:
Right #5
Right #4
Right #3
Common #2
Common #1
EOF
'
test_expect_success 'shortlog for two branches' '
test_config merge.log true &&
test_unconfig merge.summary &&
git checkout main &&
test_tick &&
git fetch . left right &&
git fmt-merge-msg <.git/FETCH_HEAD >actual1 &&
test_unconfig merge.log &&
test_config merge.summary true &&
git checkout main &&
test_tick &&
git fetch . left right &&
git fmt-merge-msg <.git/FETCH_HEAD >actual2 &&
test_config merge.log yes &&
test_unconfig merge.summary &&
git checkout main &&
test_tick &&
git fetch . left right &&
git fmt-merge-msg <.git/FETCH_HEAD >actual3 &&
test_unconfig merge.log &&
test_config merge.summary yes &&
git checkout main &&
test_tick &&
git fetch . left right &&
git fmt-merge-msg <.git/FETCH_HEAD >actual4 &&
test_cmp expected actual1 &&
test_cmp expected actual2 &&
test_cmp expected actual3 &&
test_cmp expected actual4
'
test_expect_success 'merge-msg -F' '
test_unconfig merge.log &&
test_config merge.summary yes &&
git checkout main &&
test_tick &&
git fetch . left right &&
git fmt-merge-msg -F .git/FETCH_HEAD >actual &&
test_cmp expected actual
'
test_expect_success 'merge-msg -F in subdirectory' '
test_unconfig merge.log &&
test_config merge.summary yes &&
git checkout main &&
test_tick &&
git fetch . left right &&
mkdir sub &&
cp .git/FETCH_HEAD sub/FETCH_HEAD &&
(
cd sub &&
git fmt-merge-msg -F FETCH_HEAD >../actual
) &&
test_cmp expected actual
'
test_expect_success 'merge-msg with nothing to merge' '
test_unconfig merge.log &&
test_config merge.summary yes &&
(
cd remote &&
git checkout -b unrelated &&
test_tick &&
git fetch origin &&
git fmt-merge-msg <.git/FETCH_HEAD >../actual
) &&
tests: use 'test_must_be_empty' instead of 'test_cmp <empty> <out>' Using 'test_must_be_empty' is shorter and more idiomatic than >empty && test_cmp empty out as it saves the creation of an empty file. Furthermore, sometimes the expected empty file doesn't have such a descriptive name like 'empty', and its creation is far away from the place where it's finally used for comparison (e.g. in 't7600-merge.sh', where two expected empty files are created in the 'setup' test, but are used only about 500 lines later). These cases were found by instrumenting 'test_cmp' to error out the test script when it's used to compare empty files, and then converted manually. Note that even after this patch there still remain a lot of cases where we use 'test_cmp' to check empty files: - Sometimes the expected output is not hard-coded in the test, but 'test_cmp' is used to ensure that two similar git commands produce the same output, and that output happens to be empty, e.g. the test 'submodule update --merge - ignores --merge for new submodules' in 't7406-submodule-update.sh'. - Repetitive common tasks, including preparing the expected results and running 'test_cmp', are often extracted into a helper function, and some of this helper's callsites expect no output. - For the same reason as above, the whole 'test_expect_success' block is within a helper function, e.g. in 't3070-wildmatch.sh'. - Or 'test_cmp' is invoked in a loop, e.g. the test 'cvs update (-p)' in 't9400-git-cvsserver-server.sh'. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-19 23:57:25 +02:00
test_must_be_empty actual
'
test_expect_success 'merge-msg tag' '
cat >expected <<-EOF &&
Merge tag ${apos}tag-r3${apos}
* tag ${apos}tag-r3${apos}:
Right #3
Common #2
Common #1
EOF
test_unconfig merge.log &&
test_config merge.summary yes &&
git checkout main &&
test_tick &&
git fetch . tag tag-r3 &&
git fmt-merge-msg <.git/FETCH_HEAD >actual &&
test_cmp expected actual
'
test_expect_success 'merge-msg two tags' '
cat >expected <<-EOF &&
Merge tags ${apos}tag-r3${apos} and ${apos}tag-l5${apos}
* tag ${apos}tag-r3${apos}:
Right #3
Common #2
Common #1
# By Another Author (3) and A U Thor (2)
# Via Another Committer
* tag ${apos}tag-l5${apos}:
Left #5
Left #4
Left #3
Common #2
Common #1
EOF
test_unconfig merge.log &&
test_config merge.summary yes &&
git checkout main &&
test_tick &&
git fetch . tag tag-r3 tag tag-l5 &&
git fmt-merge-msg <.git/FETCH_HEAD >actual &&
test_cmp expected actual
'
test_expect_success 'merge-msg tag and branch' '
cat >expected <<-EOF &&
Merge branch ${apos}left${apos}, tag ${apos}tag-r3${apos}
* tag ${apos}tag-r3${apos}:
Right #3
Common #2
Common #1
# By Another Author (3) and A U Thor (2)
# Via Another Committer
* left:
Left #5
Left #4
Left #3
Common #2
Common #1
EOF
test_unconfig merge.log &&
test_config merge.summary yes &&
git checkout main &&
test_tick &&
git fetch . tag tag-r3 left &&
git fmt-merge-msg <.git/FETCH_HEAD >actual &&
test_cmp expected actual
'
test_expect_success 'merge-msg lots of commits' '
{
cat <<-EOF &&
Merge branch ${apos}long${apos}
* long: (35 commits)
EOF
i=29 &&
while test $i -gt 9
do
echo " $i" &&
i=$(($i-1)) || return 1
done &&
echo " ..."
} >expected &&
test_config merge.summary yes &&
git checkout main &&
test_tick &&
git fetch . long &&
git fmt-merge-msg <.git/FETCH_HEAD >actual &&
test_cmp expected actual
'
test_expect_success 'merge-msg with "merging" an annotated tag' '
test_config merge.log true &&
git checkout main^0 &&
git commit --allow-empty -m "One step ahead" &&
git tag -a -m "An annotated one" annote HEAD &&
git checkout main &&
git fetch . annote &&
git fmt-merge-msg <.git/FETCH_HEAD >actual &&
{
cat <<-\EOF
Merge tag '\''annote'\''
An annotated one
* tag '\''annote'\'':
One step ahead
EOF
} >expected &&
test_cmp expected actual &&
test_when_finished "git reset --hard" &&
annote=$(git rev-parse annote) &&
git merge --no-commit --no-ff $annote &&
{
cat <<-EOF
Merge tag '\''$annote'\''
An annotated one
* tag '\''$annote'\'':
One step ahead
EOF
} >expected &&
test_cmp expected .git/MERGE_MSG
'
merge: allow to pretend a merge is made into a different branch When a series of patches for a topic-B depends on having topic-A, the workflow to prepare the topic-B branch would look like this: $ git checkout -b topic-B main $ git merge --no-ff --no-edit topic-A $ git am <mbox-for-topic-B When topic-A gets updated, recreating the first merge and rebasing the rest of the topic-B, all on detached HEAD, is a useful technique. After updating topic-A with its new round of patches: $ git checkout topic-B $ prev=$(git rev-parse 'HEAD^{/^Merge branch .topic-A. into}') $ git checkout --detach $prev^1 $ git merge --no-ff --no-edit topic-A $ git rebase --onto HEAD $prev @{-1}^0 $ git checkout -B @{-1} This will (0) check out the current topic-B. (1) find the previous merge of topic-A into topic-B. (2) detach the HEAD to the parent of the previous merge. (3) merge the updated topic-A to it. (4) reapply the patches to rebuild the rest of topic-B. (5) update topic-B with the result. without contaminating the reflog of topic-B too much. topic-B@{1} is the "logically previous" state before topic-A got updated, for example. At (4), comparison (e.g. range-diff) between HEAD and @{-1} is a meaningful way to sanity check the result, and the same can be done at (5) by comparing topic-B and topic-B@{1}. But there is one glitch. The merge into the detached HEAD done in the step (3) above gives us "Merge branch 'topic-A' into HEAD", and does not say "into topic-B". Teach the "--into-name=<branch>" option to "git merge" and its underlying "git fmt-merge-message", to pretend as if we were merging into <branch>, no matter what branch we are actually merging into, when they prepare the merge message. The pretend name honors the usual "into <target>" suppression mechanism, which can be seen in the tests added here. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-20 23:53:43 +01:00
test_expect_success 'merge --into-name=<name>' '
test_when_finished "git checkout main" &&
git checkout -B side main &&
git commit --allow-empty -m "One step ahead" &&
git checkout --detach main &&
git merge --no-ff side &&
git show -s --format="%s" >full.0 &&
head -n1 full.0 >actual &&
# expect that HEAD is shown as-is
grep -e "Merge branch .side. into HEAD$" actual &&
git reset --hard main &&
git merge --no-ff --into-name=main side &&
git show -s --format="%s" >full.1 &&
head -n1 full.1 >actual &&
# expect that we pretend to be merging to main, that is suppressed
grep -e "Merge branch .side.$" actual &&
git checkout -b throwaway main &&
git merge --no-ff --into-name=main side &&
git show -s --format="%s" >full.2 &&
head -n1 full.2 >actual &&
# expect that we pretend to be merging to main, that is suppressed
grep -e "Merge branch .side.$" actual
'
test_expect_success 'merge.suppressDest configuration' '
merge: allow to pretend a merge is made into a different branch When a series of patches for a topic-B depends on having topic-A, the workflow to prepare the topic-B branch would look like this: $ git checkout -b topic-B main $ git merge --no-ff --no-edit topic-A $ git am <mbox-for-topic-B When topic-A gets updated, recreating the first merge and rebasing the rest of the topic-B, all on detached HEAD, is a useful technique. After updating topic-A with its new round of patches: $ git checkout topic-B $ prev=$(git rev-parse 'HEAD^{/^Merge branch .topic-A. into}') $ git checkout --detach $prev^1 $ git merge --no-ff --no-edit topic-A $ git rebase --onto HEAD $prev @{-1}^0 $ git checkout -B @{-1} This will (0) check out the current topic-B. (1) find the previous merge of topic-A into topic-B. (2) detach the HEAD to the parent of the previous merge. (3) merge the updated topic-A to it. (4) reapply the patches to rebuild the rest of topic-B. (5) update topic-B with the result. without contaminating the reflog of topic-B too much. topic-B@{1} is the "logically previous" state before topic-A got updated, for example. At (4), comparison (e.g. range-diff) between HEAD and @{-1} is a meaningful way to sanity check the result, and the same can be done at (5) by comparing topic-B and topic-B@{1}. But there is one glitch. The merge into the detached HEAD done in the step (3) above gives us "Merge branch 'topic-A' into HEAD", and does not say "into topic-B". Teach the "--into-name=<branch>" option to "git merge" and its underlying "git fmt-merge-message", to pretend as if we were merging into <branch>, no matter what branch we are actually merging into, when they prepare the merge message. The pretend name honors the usual "into <target>" suppression mechanism, which can be seen in the tests added here. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-20 23:53:43 +01:00
test_when_finished "git checkout main" &&
git checkout -B side main &&
git commit --allow-empty -m "One step ahead" &&
git checkout main &&
git fetch . side &&
git -c merge.suppressDest="" fmt-merge-msg <.git/FETCH_HEAD >full.1 &&
head -n1 full.1 >actual &&
grep -e "Merge branch .side. into main" actual &&
git -c merge.suppressDest="mast" fmt-merge-msg <.git/FETCH_HEAD >full.2 &&
head -n1 full.2 >actual &&
grep -e "Merge branch .side. into main$" actual &&
git -c merge.suppressDest="ma?*[rn]" fmt-merge-msg <.git/FETCH_HEAD >full.3 &&
head -n1 full.3 >actual &&
grep -e "Merge branch .side." actual &&
merge: allow to pretend a merge is made into a different branch When a series of patches for a topic-B depends on having topic-A, the workflow to prepare the topic-B branch would look like this: $ git checkout -b topic-B main $ git merge --no-ff --no-edit topic-A $ git am <mbox-for-topic-B When topic-A gets updated, recreating the first merge and rebasing the rest of the topic-B, all on detached HEAD, is a useful technique. After updating topic-A with its new round of patches: $ git checkout topic-B $ prev=$(git rev-parse 'HEAD^{/^Merge branch .topic-A. into}') $ git checkout --detach $prev^1 $ git merge --no-ff --no-edit topic-A $ git rebase --onto HEAD $prev @{-1}^0 $ git checkout -B @{-1} This will (0) check out the current topic-B. (1) find the previous merge of topic-A into topic-B. (2) detach the HEAD to the parent of the previous merge. (3) merge the updated topic-A to it. (4) reapply the patches to rebuild the rest of topic-B. (5) update topic-B with the result. without contaminating the reflog of topic-B too much. topic-B@{1} is the "logically previous" state before topic-A got updated, for example. At (4), comparison (e.g. range-diff) between HEAD and @{-1} is a meaningful way to sanity check the result, and the same can be done at (5) by comparing topic-B and topic-B@{1}. But there is one glitch. The merge into the detached HEAD done in the step (3) above gives us "Merge branch 'topic-A' into HEAD", and does not say "into topic-B". Teach the "--into-name=<branch>" option to "git merge" and its underlying "git fmt-merge-message", to pretend as if we were merging into <branch>, no matter what branch we are actually merging into, when they prepare the merge message. The pretend name honors the usual "into <target>" suppression mechanism, which can be seen in the tests added here. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-20 23:53:43 +01:00
! grep -e " into main$" actual &&
git checkout --detach HEAD &&
git -c merge.suppressDest="main" fmt-merge-msg <.git/FETCH_HEAD >full.4 &&
head -n1 full.4 >actual &&
grep -e "Merge branch .side. into HEAD$" actual &&
git -c merge.suppressDest="main" fmt-merge-msg \
--into-name=main <.git/FETCH_HEAD >full.5 &&
head -n1 full.5 >actual &&
grep -e "Merge branch .side." actual &&
! grep -e " into main$" actual &&
! grep -e " into HEAD$" actual
'
test_done