git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Eric W. Biederman" <ebiederm@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Taylor Blau <me@ttaylorr.com>,
	"brian m. carlson" <sandals@crustytoothpaste.net>,
	Elijah Newren <newren@gmail.com>,
	git@vger.kernel.org
Subject: Re: [PATCH v3] bulk-checkin: only support blobs in index_bulk_checkin
Date: Wed, 27 Sep 2023 15:06:40 -0500	[thread overview]
Message-ID: <87a5t7js8f.fsf@gmail.froward.int.ebiederm.org> (raw)
In-Reply-To: <xmqq7cobmvjt.fsf@gitster.g> (Junio C. Hamano's message of "Wed, 27 Sep 2023 09:26:46 -0700")

Junio C Hamano <gitster@pobox.com> writes:

> Taylor Blau <me@ttaylorr.com> writes:
>
>> I am not sure that I follow. If we have an address in memory from which
>> we want to stream raw bytes directly to the packfile, that should work
>> for all objects regardless of type, no?
>
> For a single hash world, yes.  For keeping track of "the other hash"
> and correspondence, you need to (1) interpret the contents of the
> object (e.g., if you received a tree contents for SHA-1 repository,
> you'd need to split them into tree entries and know which parts of
> the bytestream are SHA-1 hashes of the tree contebnts), (2) come
> up with the corresponding tree contents in the SHA-256 world (you
> should be able to do that now you know SHA-1 names of the objects
> directly referred to by the tree) and hash that using SHA-256, and
> (3) remember the SHA-1 and the SHA-256 name correspondence of the
> tree object you just hashed, in addition to the usual (4) hashing
> the contents using SHA-1 hash algorithm without caring what the byte
> stream represents.

If it helps I just posted a patchset that implements what it takes
to deal with objects small enough to live in-core.

You can read object-file-convert.c to see what it takes to generate
an object in the other hash function world.

The exercise for the reader is how to apply this to objects that
are too large to fit in memory.

Eric


  reply	other threads:[~2023-09-27 20:06 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-20  3:52 [PATCH v2] bulk-checkin: only support blobs in index_bulk_checkin Eric W. Biederman
2023-09-20  6:59 ` Junio C Hamano
2023-09-20 12:24   ` Eric W. Biederman
2023-09-26 15:58     ` [PATCH v3] " Eric W. Biederman
2023-09-26 21:48       ` Junio C Hamano
2023-09-27  1:38         ` Taylor Blau
2023-09-27  4:08           ` Junio C Hamano
2023-09-27 14:34             ` Taylor Blau
2023-09-27 16:26               ` Junio C Hamano
2023-09-27 20:06                 ` Eric W. Biederman [this message]
2023-09-27 20:13           ` Eric W. Biederman
2023-09-28  9:39       ` Oswald Buddenhagen

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=87a5t7js8f.fsf@gmail.froward.int.ebiederm.org \
    --to=ebiederm@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=me@ttaylorr.com \
    --cc=newren@gmail.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.
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).