Patryk Obara writes:
> Junio C Hamano wrote:
>
>> I said this is OK for "null" because we assume we will use ^\0{len}$
>> for any hash function we choose as the "impossible" value, and for
>> that particular use pattern, we do not need such a union. Just
>> letting the caller peek at an appropr
Junio C Hamano wrote:
> I said this is OK for "null" because we assume we will use ^\0{len}$
> for any hash function we choose as the "impossible" value, and for
> that particular use pattern, we do not need such a union. Just
> letting the caller peek at an appropriate number of bytes at the
>
Stefan Beller writes:
> Once we have 2 hash functions usable in a local Git installation,
> this would be wasteful for the smaller hash function (and the
> related grafts).
>
> I think Jonathan once envisioned an 'optimized' version as a
> second step, maybe this is a good time to discuss how we'
On Tue, Aug 15, 2017 at 11:23 AM, Junio C Hamano wrote:
> Patryk Obara writes:
>
>> This prevents compilation error if GIT_MAX_RAWSZ is different than 20.
>>
>> Signed-off-by: Patryk Obara
>> ---
>> sha1_file.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> I think this is OK for
Patryk Obara writes:
> This prevents compilation error if GIT_MAX_RAWSZ is different than 20.
>
> Signed-off-by: Patryk Obara
> ---
> sha1_file.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
I think this is OK for "null" thing, but in general I feel
ambivalent when I see the use of
This prevents compilation error if GIT_MAX_RAWSZ is different than 20.
Signed-off-by: Patryk Obara
---
sha1_file.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sha1_file.c b/sha1_file.c
index b60ae15..f5b5bec 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -32,7 +32,7 @@
#d
6 matches
Mail list logo