Duy Nguyen 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
form of identifier as the
On Sun, Mar 15, 2015 at 5:19 AM, Junio C Hamano wrote:
> Duy Nguyen writes:
>
>>> Anyway, wouldn't this be all academic? I do not see how you would
>>> keep the object name in the format in-core, as the
>>> obj_hash[] is a hashtable keyed by , and even when we switch
>>> to a different hash, I
Duy Nguyen writes:
>> Anyway, wouldn't this be all academic? I do not see how you would
>> keep the object name in the format in-core, as the
>> obj_hash[] is a hashtable keyed by , and even when we switch
>> to a different hash, I cannot see how such a table to ensure the
>> singleton-ness of
On Fri, Mar 13, 2015 at 1:03 PM, Junio C Hamano wrote:
>>> To me, 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 the object name up
Many places throughout the code use "unsigned char [20]" to store object IDs
(SHA-1 values). This leads to lots of hardcoded numbers throughout the
codebase. It also leads to confusion about the purposes of a buffer.
Introduce a structure for object IDs. This allows us to obtain the benefits
of
Duy Nguyen writes:
>> You mean "if it came in format, convert it down to
>> 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
> instead of the _by
On Fri, Mar 13, 2015 at 1:24 AM, Junio C Hamano wrote:
> Duy Nguyen 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
>>
Junio C Hamano writes:
> Duy Nguyen 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 carryin
Duy Nguyen 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 object id around
On Thu, Mar 12, 2015 at 5:46 PM, brian m. carlson
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 specific to th
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 i
On 03/12/2015 01:26 AM, Junio C Hamano wrote:
> "brian m. carlson" 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 wr
On Wed, Mar 11, 2015 at 05:26:56PM -0700, Junio C Hamano wrote:
"brian m. carlson" 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.
Yeah,
"brian m. carlson" 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 Michael:
> 4. We con
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 * GIT_SHA1
Many places throughout the code use "unsigned char [20]" to store object IDs
(SHA-1 values). This leads to lots of hardcoded numbers throughout the
codebase. It also leads to confusion about the purposes of a buffer.
Introduce a structure for object IDs. This allows us to obtain the benefits
of
16 matches
Mail list logo
