Duy Nguyen pclo...@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
Duy Nguyen pclo...@gmail.com writes:
Anyway, wouldn't this be all academic? I do not see how you would
keep the object name in the pack, nth format in-core, as the
obj_hash[] is a hashtable keyed by sha-1, and even when we switch
to a different hash, I cannot see how such a table to ensure
On Sun, Mar 15, 2015 at 5:19 AM, Junio C Hamano gits...@pobox.com wrote:
Duy Nguyen pclo...@gmail.com writes:
Anyway, wouldn't this be all academic? I do not see how you would
keep the object name in the pack, nth format in-core, as the
obj_hash[] is a hashtable keyed by sha-1, and even when
On Fri, Mar 13, 2015 at 1:03 PM, Junio C Hamano gits...@pobox.com wrote:
To me, pack, offset information smells to belong more to a struct
object (or its subclass) as an optional annotation---when a caller
is asked to parse_object(), you would bypass the sha1_read_file()
that goes and looks
Duy Nguyen pclo...@gmail.com writes:
You mean if it came in pack, offset format, convert it down to
sha1 until the last second that it is needed (e.g. need to put
that in a tree object in order to compute the object name of the
containing tree object)?
I picked my words poorly. It should be
On Wed, Mar 11, 2015 at 05:26:56PM -0700, Junio C Hamano wrote:
brian m. carlson sand...@crustytoothpaste.net writes:
Michael Haggerty recommended that I call the structure element sha1
instead of oid in case we want to turn this into a union if we decide to
go the additional hash route.
I'd
On Thu, Mar 12, 2015 at 11:28:10AM +0100, Michael Haggerty wrote:
On 03/12/2015 01:26 AM, Junio C Hamano wrote:
And that would break the abstraction effort if you start calling the
field with a name that is specific to the underlying hash function.
The caller has to change o-sha1 to o-sha256
On 03/12/2015 01:26 AM, Junio C Hamano wrote:
brian m. carlson sand...@crustytoothpaste.net writes:
Michael Haggerty recommended that I call the structure element sha1
instead of oid in case we want to turn this into a union if we decide to
go the additional hash route.
I'd advise against
On Thu, Mar 12, 2015 at 5:46 PM, brian m. carlson
sand...@crustytoothpaste.net wrote:
On Thu, Mar 12, 2015 at 11:28:10AM +0100, Michael Haggerty wrote:
On 03/12/2015 01:26 AM, Junio C Hamano wrote:
And that would break the abstraction effort if you start calling the
field with a name that is
Junio C Hamano gits...@pobox.com writes:
Duy Nguyen pclo...@gmail.com writes:
This may or may not fall into the mix different hash functions
category. In pack files version 4, trees are encoded to point to other
trees or blobs by a (pack, offset) tuple. It would be great if the new
Duy Nguyen pclo...@gmail.com writes:
This may or may not fall into the mix different hash functions
category. In pack files version 4, trees are encoded to point to other
trees or blobs by a (pack, offset) tuple. It would be great if the new
object_id could support carrying this kind of
On Fri, Mar 13, 2015 at 1:24 AM, Junio C Hamano gits...@pobox.com wrote:
Duy Nguyen pclo...@gmail.com writes:
This may or may not fall into the mix different hash functions
category. In pack files version 4, trees are encoded to point to other
trees or blobs by a (pack, offset) tuple. It
On Tue, Mar 10, 2015 at 07:38:42PM -0700, Kyle J. McKay wrote:
GIT_SHA1_HEXSZ will always be exactly 2 * GIT_SHA1_RAWSZ, right? In
fact, if it's not things will almost certainly break, yes?
Does it make more sense then to reflect this requirement by using:
#define GIT_SHA1_HEXSZ (2 *
brian m. carlson sand...@crustytoothpaste.net writes:
Michael Haggerty recommended that I call the structure element sha1
instead of oid in case we want to turn this into a union if we decide to
go the additional hash route.
I'd advise against it.
As I wrote in $gmane/265337 in response to
14 matches
Mail list logo
