From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: "brian m. carlson" <sandals@crustytoothpaste.net>, git@vger.kernel.org
Subject: Re: [PATCH v2 07/24] t6300: abstract away SHA-1-specific constants
Date: Mon, 24 Feb 2020 13:12:04 -0500 [thread overview]
Message-ID: <20200224181204.GA2130083@coredump.intra.peff.net> (raw)
In-Reply-To: <xmqqsgizrhjv.fsf@gitster-ct.c.googlers.com>
On Mon, Feb 24, 2020 at 10:01:08AM -0800, Junio C Hamano wrote:
> > -test_atom head objectsize 171
> > -test_atom head objectsize:disk 138
> > -test_atom head deltabase 0000000000000000000000000000000000000000
> > +test_atom head objectsize $((131 + hexlen))
>
> 171 == 131 + 40 and that is because we are looking at the initial
> commit, whose contents has a single object name (i.e. its tree).
I wonder if it would be more readable to just pipe "cat-file" through
"wc -c", rather than hard-coding. Then there's no magic number at all.
> > +test_atom head objectsize:disk $disklen
Likewise for $disklen, if it's a loose object we could just get the
information from the filesystem. That would stop us caring about the
hash, _and_ it would make us robust to random changes in the zlib
compression.
I'm not sure if we also check packed objects. If so, you can compute the
size from the output of show-index, which gives the offsets of each
object. That's also how Git does it internally, though, so I'm not sure
if that is getting too close to just testing nothing (but IMHO the thing
we're really covering here is the format routines).
-Peff
next prev parent reply other threads:[~2020-02-24 18:12 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-22 20:17 [PATCH v2 00/24] SHA-256 stage 4 implementation, part 1/3 brian m. carlson
2020-02-22 20:17 ` [PATCH v2 01/24] builtin/pack-objects: make hash agnostic brian m. carlson
2020-02-23 21:57 ` Jeff King
2020-02-24 3:01 ` Jeff King
2020-02-24 3:42 ` brian m. carlson
2020-02-24 4:20 ` Jeff King
2020-02-22 20:17 ` [PATCH v2 02/24] hash: implement and use a context cloning function brian m. carlson
2020-02-22 20:17 ` [PATCH v2 03/24] hex: introduce parsing variants taking hash algorithms brian m. carlson
2020-02-22 20:17 ` [PATCH v2 04/24] hex: add functions to parse hex object IDs in any algorithm brian m. carlson
2020-02-22 20:17 ` [PATCH v2 05/24] repository: require a build flag to use SHA-256 brian m. carlson
2020-02-22 20:17 ` [PATCH v2 06/24] t: use hash-specific lookup tables to define test constants brian m. carlson
2020-02-22 20:17 ` [PATCH v2 07/24] t6300: abstract away SHA-1-specific constants brian m. carlson
2020-02-24 18:01 ` Junio C Hamano
2020-02-24 18:12 ` Jeff King [this message]
2020-02-24 20:41 ` Junio C Hamano
2020-02-22 20:17 ` [PATCH v2 08/24] t6300: make hash algorithm independent brian m. carlson
2020-02-22 20:17 ` [PATCH v2 09/24] t/helper/test-dump-split-index: initialize git repository brian m. carlson
2020-02-22 20:17 ` [PATCH v2 10/24] t/helper: initialize repository if necessary brian m. carlson
2020-02-24 18:05 ` Junio C Hamano
2020-02-25 0:05 ` brian m. carlson
2020-02-22 20:17 ` [PATCH v2 11/24] t/helper: make repository tests hash independent brian m. carlson
2020-02-22 20:17 ` [PATCH v2 12/24] setup: allow check_repository_format to read repository format brian m. carlson
2020-02-22 20:17 ` [PATCH v2 13/24] builtin/init-db: allow specifying hash algorithm on command line brian m. carlson
2020-02-24 18:14 ` Junio C Hamano
2020-02-25 0:11 ` brian m. carlson
2020-02-22 20:17 ` [PATCH v2 14/24] builtin/init-db: add environment variable for new repo hash brian m. carlson
2020-02-22 20:17 ` [PATCH v2 15/24] init-db: move writing repo version into a function brian m. carlson
2020-02-22 20:17 ` [PATCH v2 16/24] worktree: allow repository version 1 brian m. carlson
2020-02-22 20:17 ` [PATCH v2 17/24] commit: use expected signature header for SHA-256 brian m. carlson
2020-02-24 18:24 ` Junio C Hamano
2020-02-22 20:17 ` [PATCH v2 18/24] gpg-interface: improve interface for parsing tags brian m. carlson
2020-02-24 18:26 ` Junio C Hamano
2020-02-25 10:29 ` Johannes Schindelin
2020-02-25 19:25 ` Junio C Hamano
2020-02-26 3:05 ` brian m. carlson
2020-02-26 3:11 ` Junio C Hamano
2020-02-26 2:23 ` brian m. carlson
2020-02-27 13:24 ` Johannes Schindelin
2020-02-27 15:06 ` Junio C Hamano
2020-02-22 20:17 ` [PATCH v2 19/24] tag: store SHA-256 signatures in a header brian m. carlson
2020-02-24 18:30 ` Junio C Hamano
2020-02-22 20:17 ` [PATCH v2 20/24] fast-import: permit reading multiple marks files brian m. carlson
2020-06-05 16:14 ` Junio C Hamano
2020-06-05 16:26 ` Junio C Hamano
2020-06-05 22:39 ` brian m. carlson
2020-06-05 22:53 ` Junio C Hamano
2020-02-22 20:17 ` [PATCH v2 21/24] fast-import: add helper function for inserting mark object entries brian m. carlson
2020-02-22 20:17 ` [PATCH v2 22/24] fast-import: make find_marks work on any mark set brian m. carlson
2020-02-22 20:17 ` [PATCH v2 23/24] fast-import: add a generic function to iterate over marks brian m. carlson
2020-02-22 20:17 ` [PATCH v2 24/24] fast-import: add options for rewriting submodules brian m. carlson
2020-02-24 18:34 ` [PATCH v2 00/24] SHA-256 stage 4 implementation, part 1/3 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
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=20200224181204.GA2130083@coredump.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=sandals@crustytoothpaste.net \
/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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).