All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Eric Sunshine via GitGitGadget" <gitgitgadget@gmail.com>
To: git@vger.kernel.org
Cc: Elijah Newren <newren@gmail.com>,
	Eric Sunshine <sunshine@sunshineco.com>,
	Eric Sunshine <sunshine@sunshineco.com>
Subject: [PATCH 1/3] t4301: account for behavior differences between sed implementations
Date: Sun, 28 Aug 2022 05:17:57 +0000	[thread overview]
Message-ID: <a3576ff88226ffbdcc58bf837e4cd97dd299f77b.1661663880.git.gitgitgadget@gmail.com> (raw)
In-Reply-To: <pull.1339.git.1661663879.gitgitgadget@gmail.com>

From: Eric Sunshine <sunshine@sunshineco.com>

It is a common pattern in this script to write the result of
`merge-tree -z` (NUL-termination mode) to an "actual" file and then
manually append a newline to that file so that it can be diff'd easily
with a hand-crafted "expect" file which itself ends with a newline since
it has been created by standard Unix tools which terminate lines by
default. For instance:

    git merge-tree --write-tree -z ... >out &&
    printf "\\n" >>out
    anonymize_hash out >actual &&
    q_to_nul <<-EOF >expect &&
    ...
    EOF
    test_cmp expect actual

However, one test gets this backward:

    git merge-tree --write-tree -z ... >out &&
    anonymize_hash out >actual &&
    printf "\\n" >>actual

which means that, unlike all other cases, when anonymize_hash() is
called, the file being anonymized does not end with a newline. As a
result, this test fails on some platforms.

anonymize_hash() is implemented like this:

    anonymize_hash() {
        sed -e "s/[0-9a-f]\{40,\}/HASH/g" "$@"
    }

The problem arises due to differences in behavior of various `sed`
implementations when fed an incomplete line (lacking a newline).
Although most modern `sed` implementations output such a line
unmolested (i.e. without a newline), some older `sed` implementations
forcibly add a newline to the incomplete line (giving the output an
extra unexpected newline), while other very old implementations simply
swallow an incomplete line and don't emit it at all (making the output
shorter than expected).

Fix this test by manually adding the newline before passing it through
`sed`, thus ensuring identical behavior with all `sed` implementation,
and bringing the test in line with other tests in this script.

Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
---
 t/t4301-merge-tree-write-tree.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/t/t4301-merge-tree-write-tree.sh b/t/t4301-merge-tree-write-tree.sh
index c5fd56df28f..d44c7767f30 100755
--- a/t/t4301-merge-tree-write-tree.sh
+++ b/t/t4301-merge-tree-write-tree.sh
@@ -760,8 +760,8 @@ test_expect_success 'NUL terminated conflicted file "lines"' '
 	git commit -m "Renamed numbers" &&
 
 	test_expect_code 1 git merge-tree --write-tree -z tweak1 side2 >out &&
+	printf "\\n" >>out &&
 	anonymize_hash out >actual &&
-	printf "\\n" >>actual &&
 
 	# Expected results:
 	#   "greeting" should merge with conflicts
-- 
gitgitgadget


  reply	other threads:[~2022-08-28  5:18 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-28  5:17 [PATCH 0/3] fix failing t4301 test and &&-chain breakage Eric Sunshine via GitGitGadget
2022-08-28  5:17 ` Eric Sunshine via GitGitGadget [this message]
2022-08-28  5:17 ` [PATCH 2/3] t4031: fix broken &&-chains and add missing loop termination Eric Sunshine via GitGitGadget
2022-08-28  5:17 ` [PATCH 3/3] t4301: emit blank line in more idiomatic fashion Eric Sunshine via GitGitGadget
2022-08-28 20:05 ` [PATCH 0/3] fix failing t4301 test and &&-chain breakage Junio C Hamano
2022-08-28 20:46   ` Eric Sunshine
2022-08-29  5:36     ` Junio C Hamano
2022-08-30  2:53   ` Elijah Newren
2022-08-30  2:56     ` Eric Sunshine
2022-08-30  2:59       ` Elijah Newren
2022-08-30  2:52 ` Elijah Newren
2022-08-30 14:02   ` Johannes Schindelin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a3576ff88226ffbdcc58bf837e4cd97dd299f77b.1661663880.git.gitgitgadget@gmail.com \
    --to=gitgitgadget@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=newren@gmail.com \
    --cc=sunshine@sunshineco.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.