From: Junio C Hamano <gitster@pobox.com>
To: Duy Nguyen <pclouds@gmail.com>
Cc: "brian m. carlson" <sandals@crustytoothpaste.net>,
Michael Haggerty <mhagger@alum.mit.edu>,
"Kyle J. McKay" <mackyle@gmail.com>,
Git Mailing List <git@vger.kernel.org>,
Andreas Schwab <schwab@linux-m68k.org>
Subject: Re: [PATCH v2 01/10] Define a structure for object IDs.
Date: Sat, 14 Mar 2015 19:32:29 -0700 [thread overview]
Message-ID: <xmqqy4mzuh1e.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <CACsJy8CK=0QpsMpZKN6Js99xFRD6mpJW1id2BBQDMsV1DaHiPg@mail.gmail.com> (Duy Nguyen's message of "Sun, 15 Mar 2015 07:17:07 +0700")
Duy Nguyen <pclouds@gmail.com> writes:
> Notice that the first time pack->obj[] is filled using
> lookup_object(). So yes, the hash table has all the pointers that
> pack->obj[] has.
Are we talking about the same thing?
By "the hash table", I mean **obj_hash that is a hashtable that uses
<sha-1> form of identifier as the key. So "the hash table has all
the pointers" sounds like all the objects you instantiate from a v4
packfile needs their object name known in the <sha-1> form anyway
when it gets instantiated (or more importantly, when you realize
there is another copy of it already in the **obj_hash hashtable, you
may have to free or refrain from creating it in the first place).
As long as we use **obj_hash hashtable as "all the objects this
process cares about in the world" and "struct object_id.hash" as the
key into it, I do not think <pack,nth> representation belongs to
that layer.
I do think <pack,nth> representation has its use as a short-cut
mechanism to reach an indirectly referenced object directly without
instantiating intermediate objects when dealing with an extended
SHA-1 expression (cf. "v1.0^0:t" example in a few messages
upthread). I just think it does not belong to "struct object_id"
that are used to refer to in-core objects.
next prev parent reply other threads:[~2015-03-15 2:35 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-07 23:23 [PATCH v2 00/10] Use a structure for object IDs brian m. carlson
2015-03-07 23:23 ` [PATCH v2 01/10] Define " brian m. carlson
[not found] ` <CEA07500-9F47-4B24-AD5D-1423A601A4DD@gmail.com>
2015-03-11 22:08 ` brian m. carlson
2015-03-12 0:26 ` Junio C Hamano
2015-03-12 9:34 ` brian m. carlson
2015-03-12 10:28 ` Michael Haggerty
2015-03-12 10:46 ` brian m. carlson
2015-03-12 11:16 ` Duy Nguyen
2015-03-12 18:24 ` Junio C Hamano
2015-03-12 18:44 ` Junio C Hamano
2015-03-13 0:58 ` Duy Nguyen
2015-03-13 6:03 ` Junio C Hamano
2015-03-14 11:49 ` Duy Nguyen
2015-03-14 22:19 ` Junio C Hamano
2015-03-15 0:17 ` Duy Nguyen
2015-03-15 2:32 ` Junio C Hamano [this message]
2015-03-07 23:23 ` [PATCH v2 02/10] Define utility functions " brian m. carlson
2015-03-08 9:57 ` Duy Nguyen
2015-03-08 14:48 ` brian m. carlson
2015-03-11 12:44 ` Michael Haggerty
2015-03-07 23:23 ` [PATCH v2 03/10] bisect.c: convert leaf functions to use struct object_id brian m. carlson
2015-03-07 23:23 ` [PATCH v2 04/10] archive.c: convert " brian m. carlson
2015-03-11 14:20 ` Michael Haggerty
2015-03-11 22:12 ` brian m. carlson
2015-03-07 23:24 ` [PATCH v2 05/10] zip: use GIT_SHA1_HEXSZ for trailers brian m. carlson
2015-03-07 23:24 ` [PATCH v2 06/10] bulk-checkin.c: convert to use struct object_id brian m. carlson
2015-03-07 23:24 ` [PATCH v2 07/10] diff: convert struct combine_diff_path to object_id brian m. carlson
2015-03-07 23:24 ` [PATCH v2 08/10] commit: convert parts to struct object_id brian m. carlson
2015-03-11 14:46 ` Michael Haggerty
2015-03-07 23:24 ` [PATCH v2 09/10] patch-id: convert to use " brian m. carlson
2015-03-07 23:24 ` [PATCH v2 10/10] apply: convert threeway_stage to object_id brian m. carlson
2015-03-08 7:43 ` [PATCH v2 00/10] Use a structure for object IDs Junio C Hamano
2015-03-11 2:38 ` Kyle J. McKay
2015-03-11 16:08 ` Michael Haggerty
2015-03-11 20:35 ` Junio C Hamano
2015-03-13 22:45 ` brian m. carlson
-- strict thread matches above, loose matches on Subject: below --
2015-03-13 23:39 brian m. carlson
2015-03-13 23:39 ` [PATCH v2 01/10] Define " brian m. carlson
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=xmqqy4mzuh1e.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=mackyle@gmail.com \
--cc=mhagger@alum.mit.edu \
--cc=pclouds@gmail.com \
--cc=sandals@crustytoothpaste.net \
--cc=schwab@linux-m68k.org \
/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.