All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Tao Klerks via GitGitGadget" <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, Tao Klerks <tao@klerks.biz>
Subject: Re: [PATCH] apply: support case-only renames in case-insensitive filesystems
Date: Sun, 12 Jun 2022 16:30:12 -0700	[thread overview]
Message-ID: <xmqqr13t8np7.fsf@gitster.g> (raw)
In-Reply-To: <pull.1257.git.1654967038802.gitgitgadget@gmail.com> (Tao Klerks via GitGitGadget's message of "Sat, 11 Jun 2022 17:03:58 +0000")

"Tao Klerks via GitGitGadget" <gitgitgadget@gmail.com> writes:

> +if ! test_have_prereq CASE_INSENSITIVE_FS
> +then
> +	test_set_prereq CASE_SENSITIVE_FS
> +	echo nuts
> +fi

You can easily say !CASE_INSENSITIVE_FS as the prerequiste, so I do
not see the point of this.  I do not see the point of "nuts", either.

But it probably is a moot point as I do not think you should do the
prerequisite at all.

Instead, you can explicitly set the core.ignorecase configuration,
i.e. "git -c core.ignorecase=yes/no", and possibly "apply --cached"
so that you do not have to worry about the case sensitivity of the
filesystem at all.

> +test_expect_success setup '
> +	echo "This is some content in the file." > file1 &&

Style.  Redirection operator ">" sticks to its operand, i.e.

	echo "This is some content in the file." >file1 &&

> +	echo "A completely different file." > file2 &&
> +	git update-index --add file1 &&
> +	git update-index --add file2 &&
> +	cat >case_only_rename_patch <<-\EOF
> +	diff --git a/file1 b/File1
> +	similarity index 100%
> +	rename from file1
> +	rename to File1
> +	EOF

You are better off not writing the diff output manually.  Instead,
you can let the test write it for you, e.g.

	echo "This is some content in the file." >file1 &&
	git update-index --add file1 &&
        file1blob=$(git rev-parse :file1) &&
	git commit -m "Initial - file1" &&
	git update-index --add --cacheinfo 100644,$file1blob,File1 &&
	git rm --cached file1 &&
	git diff --cached -M HEAD >case-only-rename-patch

If you want to be extra careful not to rely on your filesystem
corrupting the pathnames you feed (e.g. the redireciton to "file1"
might create file FILE1 on MS-DOS ;-), you could even do:

	file1blob=$(echo "This is some content in the file." |
		    git hash-object -w --stdin) &&
	file2blob=$(echo "A completeloy different contents." |
		    git hash-object -w --stdin) &&
	git update-index --add --cacheinfo 100644,$file1blob,file1 &&

	git commit -m "Initial - file1" &&
	git update-index --add --cacheinfo 100644,$file1blob,File1 &&
	git rm --cached file1 &&
	git diff --cached -M HEAD >rename-file1-to-File2 &&

	git reset --hard HEAD &&
        git update-index --add --cacheinfo 100644,$file1blob,file2 &&
	git rm --cached file1 &&
	git diff --cached -M HEAD >rename-file1-to-file2 &&

	# from here on, HEAD has file1 and file2
	git reset --hard HEAD &&
	git update-index --add --cacheinfo 100644,$file2blob,file2 &&
	git commit -m 'file1 and file2'

> +'
> +
> +test_expect_success 'refuse to apply rename patch with conflict' '
> +	cat >conflict_patch <<-\EOF &&
> +	diff --git a/file1 b/file2
> +	similarity index 100%
> +	rename from file1
> +	rename to file2
> +	EOF
> +	test_must_fail git apply --index conflict_patch

And then, you could use --cached (not --index) to bypass the working
tree altogether, which is a good way to test the feature without
getting affected by the underlying filesystem.  Check both case
sensitive and case insensitive cases:

	# Start from a known state
	git reset --hard HEAD &&
	test_must_fail git -c core.ignorecase=no apply --cached rename-file1-to-file2 &&

	# Start from a known state
	git reset --hard HEAD &&
	test_must_fail git -c core.ignorecase=yes apply --cached rename-file1-to-file2 &&

> +'
> +
> +test_expect_success CASE_SENSITIVE_FS 'refuse to apply case-only rename patch with conflict, in case-sensitive FS' '

Lose the prerequisite, replace --index with --cached, and force core.ignorecase
to both case insensitive and sensitive to check the behaviour.

> +	test_when_finished "git mv File1 file2" &&
> +	git mv file2 File1 &&
> +	test_must_fail git apply --index case_only_rename_patch
> +'
> +
> +test_expect_success 'apply case-only rename patch without conflict' '

Likewise, try both sensitive and insensitive one.

> +	git apply --index case_only_rename_patch
> +'
> +
> +test_done
>
> base-commit: 1e59178e3f65880188caedb965e70db5ceeb2d64

Thanks.


  parent reply	other threads:[~2022-06-12 23:30 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-11 17:03 [PATCH] apply: support case-only renames in case-insensitive filesystems Tao Klerks via GitGitGadget
2022-06-11 19:17 ` Junio C Hamano
2022-06-12 23:35   ` Junio C Hamano
2022-06-14  6:22     ` Tao Klerks
2022-06-15 11:24       ` Tao Klerks
2022-06-14  5:13   ` Tao Klerks
2022-06-18  0:45     ` Junio C Hamano
2022-06-18 15:34       ` Tao Klerks
2022-06-12 23:30 ` Junio C Hamano [this message]
2022-06-13 18:12   ` Junio C Hamano
2022-06-14  6:26     ` Tao Klerks
2022-06-14  6:16   ` Tao Klerks
2022-06-19 16:10 ` [PATCH v2 0/3] RFC: " Tao Klerks via GitGitGadget
2022-06-19 16:10   ` [PATCH v2 1/3] t4141: test "git apply" with core.ignorecase Junio C Hamano via GitGitGadget
2022-06-19 16:10   ` [PATCH v2 2/3] reset: new failing test for reset of case-insensitive duplicate in index Tao Klerks via GitGitGadget
2022-06-19 16:10   ` [PATCH v2 3/3] apply: support case-only renames in case-insensitive filesystems Tao Klerks via GitGitGadget
2022-10-10  4:09   ` [PATCH v2 0/3] RFC: " Tao Klerks
2023-05-28  9:59   ` [PATCH v3 0/3] " Tao Klerks via GitGitGadget
2023-05-28  9:59     ` [PATCH v3 1/3] t4142: test "git apply" with core.ignorecase Junio C Hamano via GitGitGadget
2023-05-28  9:59     ` [PATCH v3 2/3] reset: new failing test for reset of case-insensitive duplicate in index Tao Klerks via GitGitGadget
2023-05-28  9:59     ` [PATCH v3 3/3] apply: support case-only renames in case-insensitive filesystems Tao Klerks 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

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

  git send-email \
    --in-reply-to=xmqqr13t8np7.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=tao@klerks.biz \
    /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.