git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / Atom feed
From: "Elijah Newren via GitGitGadget" <gitgitgadget@gmail.com>
To: git@vger.kernel.org
Cc: Elijah Newren <newren@gmail.com>, Elijah Newren <newren@gmail.com>
Subject: [PATCH v2 2/4] t6038: remove problematic test
Date: Mon, 03 Aug 2020 18:41:18 +0000
Message-ID: <305fe534c5543cd71559ed2dca7e1657b0b8554c.1596480080.git.gitgitgadget@gmail.com> (raw)
In-Reply-To: <pull.825.v2.git.git.1596480080.gitgitgadget@gmail.com>

From: Elijah Newren <newren@gmail.com>

t6038.11, 'cherry-pick patch from after text=auto' was a test of
undefined behavior.  To make matters worse, while there are a couple
possible correct answers, this test was coded to only check for an
obviously incorrect answer.  And the final cherry on top is that the
test is marked test_expect_failure, meaning it can't provide much value,
other than possibly confusing future folks who come along and try to
work on attributes and look at existing tests.  Because of all these
problems, just remove the test.

But for any future code spelunkers, here's my understanding of the two
possible correct answers:

This test was set up so that on a branch with no .gitattributes file,
you cherry-picked a patch from a branch that had a .gitattributes file
(containing '* text=auto').  Further, the two branches had a file which
differed only in line endings.  In this situation, correct behavior is
not well defined: should the .gitattributes file affect the merge or
not?

If the .gitattributes file on the other branch should not affect the
merge, then we would have a content conflict with all three stages
different (the merge base didn't match either side).

If the .gitattributes file from the other branch should affect the
merge, then we would expect the line endings to be normalized to LF for
the version to be recorded in the repository.  This would mean that when
doing a three-way content merge on the file that differed in line
endings, that the three-way content merge would see that the versions on
both sides matched and so the cherry-pick has no conflicts and can
succeed.  The line endings in the file as recorded in the repository
will change from CRLF to LF.  The version checked out in the working
copy will depend on the platform (since there's no eol attribute defined
for the file).

Also, as a final side note, this test expected an error message that was
built assuming cherry-pick was the old scripted version, because
cherry-pick no longer uses the error message that was encoded in this
test.  So it was wrong for yet another reason.

Given that the handling of .gitattributes is not well defined and this
test was obviously broken and could do nothing but confuse future
readers, just remove it.

Signed-off-by: Elijah Newren <newren@gmail.com>
---
 t/t6038-merge-text-auto.sh | 14 --------------
 1 file changed, 14 deletions(-)

diff --git a/t/t6038-merge-text-auto.sh b/t/t6038-merge-text-auto.sh
index 27cea15533..9337745793 100755
--- a/t/t6038-merge-text-auto.sh
+++ b/t/t6038-merge-text-auto.sh
@@ -188,20 +188,6 @@ test_expect_failure 'checkout -m addition of text=auto' '
 	git diff --no-index --ignore-cr-at-eol expected file
 '
 
-test_expect_failure 'cherry-pick patch from after text=auto was added' '
-	append_cr <<-\EOF >expected &&
-	first line
-	same line
-	EOF
-
-	git config merge.renormalize true &&
-	git rm -fr . &&
-	git reset --hard b &&
-	test_must_fail git cherry-pick a >err 2>&1 &&
-	grep "[Nn]othing added" err &&
-	compare_files expected file
-'
-
 test_expect_success 'Test delete/normalize conflict' '
 	git checkout -f side &&
 	git rm -fr . &&
-- 
gitgitgadget


  parent reply	other threads:[~2020-08-03 18:41 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-02  6:33 [PATCH 0/4] Attr fixes Elijah Newren via GitGitGadget
2020-08-02  6:33 ` [PATCH 1/4] t6038: make tests fail for the right reason Elijah Newren via GitGitGadget
2020-08-02 18:17   ` Junio C Hamano
2020-08-02 19:10   ` Eric Sunshine
2020-08-03 15:06     ` Elijah Newren
2020-08-02  6:33 ` [PATCH 2/4] t6038: fix test with obviously incorrect expectations Elijah Newren via GitGitGadget
2020-08-02 19:57   ` Junio C Hamano
2020-08-03 15:36     ` Elijah Newren
2020-08-03 15:50       ` Junio C Hamano
2020-08-02  6:33 ` [PATCH 3/4] merge: make merge.renormalize work for all uses of merge machinery Elijah Newren via GitGitGadget
2020-08-02 19:23   ` Junio C Hamano
2020-08-03 15:07     ` Elijah Newren
2020-08-02  6:33 ` [PATCH 4/4] checkout: support renormalization with checkout -m <paths> Elijah Newren via GitGitGadget
2020-08-03 18:41 ` [PATCH v2 0/4] Attr fixes Elijah Newren via GitGitGadget
2020-08-03 18:41   ` [PATCH v2 1/4] t6038: make tests fail for the right reason Elijah Newren via GitGitGadget
2020-08-03 18:41   ` Elijah Newren via GitGitGadget [this message]
2020-08-03 18:41   ` [PATCH v2 3/4] merge: make merge.renormalize work for all uses of merge machinery Elijah Newren via GitGitGadget
2020-08-03 18:41   ` [PATCH v2 4/4] checkout: support renormalization with checkout -m <paths> Elijah Newren via GitGitGadget

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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=305fe534c5543cd71559ed2dca7e1657b0b8554c.1596480080.git.gitgitgadget@gmail.com \
    --to=gitgitgadget@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=newren@gmail.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

git@vger.kernel.org list mirror (unofficial, one of many)

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://public-inbox.org/git
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 git git/ http://public-inbox.org/git \
		git@vger.kernel.org
	public-inbox-index git

Example config snippet for mirrors.
Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git
	nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git
	nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git
	nntp://news.gmane.io/gmane.comp.version-control.git
 note: .onion URLs require Tor: https://www.torproject.org/

code repositories for the project(s) associated with this inbox:

	https://80x24.org/mirrors/git.git

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git