From: Junio C Hamano <gitster@pobox.com>
To: "brian m. carlson" <sandals@crustytoothpaste.net>
Cc: <git@vger.kernel.org>, Derrick Stolee <dstolee@microsoft.com>,
Stefan Beller <stefanbeller@gmail.com>,
Johannes Schindelin <Johannes.Schindelin@gmx.de>
Subject: Re: [PATCH v2 07/15] t4011: abstract away SHA-1-specific constants
Date: Mon, 28 Oct 2019 11:56:14 +0900 [thread overview]
Message-ID: <xmqqk18pa88h.fsf@gitster-ct.c.googlers.com> (raw)
In-Reply-To: <20191028005907.24985-8-sandals@crustytoothpaste.net> (brian m. carlson's message of "Mon, 28 Oct 2019 00:58:59 +0000")
"brian m. carlson" <sandals@crustytoothpaste.net> writes:
It does make sense to introduce these two additional helpers, one
that takes the contents to be hashed, and the other that takes the
name of the file that stores the contents to be hashed. The former
is handy when you need to compute an object name for a symbolic
link, and the latter is handy when you have contents already stored
in a file. But if you have a short contents in a variable, nothing
prevents you from using the former to compute an object name for a
file that would have the contents you have in the variable without
having to first create a temporary file.
It crossed my mind that it may make more logical sense to call the
former "oid_from_contents" and the latter "oid_from_file", but I'll
shortly change my position ;-)
> +# Print the short OID of a symlink with the given name.
> +symlink_oid () {
> + local oid=$(printf "%s" "$1" | git hash-object --stdin) &&
> + git rev-parse --short "$oid"
> +}
This is good.
> +# Print the short OID of the given file.
To contrast with the above, s/given/contents of the/ may make the
distinction clearer, I think.
> +short_oid () {
> + local oid=$(git hash-object "$1") &&
> + git rev-parse --short "$oid"
> +}
Given that we do not use the former helper to compute a regular
file object name without having a concrete file on the filesystem,
I do not mind calling it symlink_oid at all. But then this may want
to be called file_oid to make the contrast better, and it would
match the use of these two in a test near the end of this patch.
> test_expect_success 'diff new symlink and file' '
> - cat >expected <<-\EOF &&
> + symlink=$(symlink_oid xyzzy) &&
> + cat >expected <<-EOF &&
> diff --git a/frotz b/frotz
> new file mode 120000
> - index 0000000..7c465af
> + index 0000000..$symlink
It is a mistake to name the variable "symlink", even though
symlink_oid is a good name for this helper function.
If you were showing a change that updates the symlink RelNotes from
pointing at Documentation/RelNotes/2.0.0.txt to
Documentation/RelNotes/2.1.0.txt, for example, you would say
old=$(symlink_oid Documentation/RelNotes/2.0.0.txt) &&
new=$(symlink_oid Documentation/RelNotes/2.1.0.txt) &&
cat expect <<-EOF &&
diff --git a/RelNotes b/RelNotes
index $old..$new
...
EOF
so I'd expect $new (on the right hand side of ..) would read more
natural.
> @@ -137,14 +151,16 @@ test_expect_success SYMLINKS 'setup symlinks with attributes' '
> '
>
> test_expect_success SYMLINKS 'symlinks do not respect userdiff config by path' '
> - cat >expect <<-\EOF &&
> + file=$(short_oid file.bin) &&
> + link=$(symlink_oid file.bin) &&
Here, I do think $file and $link are good names, and that leads me
to say s/short_oid/file_oid/ would be a good idea.
> + cat >expect <<-EOF &&
> diff --git a/file.bin b/file.bin
> new file mode 100644
> - index 0000000..d95f3ad
> + index 0000000..$file
> Binary files /dev/null and b/file.bin differ
> diff --git a/link.bin b/link.bin
> new file mode 120000
> - index 0000000..dce41ec
> + index 0000000..$link
> --- /dev/null
> +++ b/link.bin
> @@ -0,0 +1 @@
next prev parent reply other threads:[~2019-10-28 2:56 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-28 0:58 [PATCH v2 00/15] SHA-256 test fixes, part 6 brian m. carlson
2019-10-28 0:58 ` [PATCH v2 01/15] t/oid-info: allow looking up hash algorithm name brian m. carlson
2019-10-28 0:58 ` [PATCH v2 02/15] t/oid-info: add empty tree and empty blob values brian m. carlson
2019-10-28 0:58 ` [PATCH v2 03/15] rev-parse: add a --show-object-format option brian m. carlson
2019-10-28 0:58 ` [PATCH v2 04/15] t1305: avoid comparing extensions brian m. carlson
2019-10-28 0:58 ` [PATCH v2 05/15] t3429: remove SHA1 annotation brian m. carlson
2019-10-28 0:58 ` [PATCH v2 06/15] t4010: abstract away SHA-1-specific constants brian m. carlson
2019-10-28 0:58 ` [PATCH v2 07/15] t4011: " brian m. carlson
2019-10-28 2:56 ` Junio C Hamano [this message]
2019-10-28 23:59 ` brian m. carlson
2019-10-28 0:59 ` [PATCH v2 08/15] t4015: " brian m. carlson
2019-10-28 0:59 ` [PATCH v2 09/15] t4027: make hash-size independent brian m. carlson
2019-10-28 0:59 ` [PATCH v2 10/15] t4034: abstract away SHA-1-specific constants brian m. carlson
2019-10-28 0:59 ` [PATCH v2 11/15] t4038: abstract away SHA-1 specific constants brian m. carlson
2019-10-28 0:59 ` [PATCH v2 12/15] t4039: abstract away SHA-1-specific constants brian m. carlson
2019-10-28 0:59 ` [PATCH v2 13/15] t4044: update test to work with SHA-256 brian m. carlson
2019-10-28 0:59 ` [PATCH v2 14/15] t4045: make hash-size independent brian m. carlson
2019-10-28 0:59 ` [PATCH v2 15/15] t4048: abstract away SHA-1-specific constants brian m. carlson
2019-10-29 2:26 ` [PATCH v2 00/15] SHA-256 test fixes, part 6 Junio C Hamano
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=xmqqk18pa88h.fsf@gitster-ct.c.googlers.com \
--to=gitster@pobox.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=dstolee@microsoft.com \
--cc=git@vger.kernel.org \
--cc=sandals@crustytoothpaste.net \
--cc=stefanbeller@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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).