Derrick Stolee writes:
>> I do not think they are wrong, but aren't the latter two somewhat
>> redundant? "num" is p->num_objects, and we call (first+1)th element
>> only after we see (first < num - 1), i.e. first+1 < num, and the
>> access to (first-1)th is done only when
On 2/28/2018 3:50 PM, Junio C Hamano wrote:
Derrick Stolee writes:
diff --git a/sha1_name.c b/sha1_name.c
index 611c7d24dd..a041d8d24f 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -547,15 +547,15 @@ static void find_abbrev_len_for_pack(struct packed_git *p,
*/
Derrick Stolee writes:
> diff --git a/sha1_name.c b/sha1_name.c
> index 611c7d24dd..a041d8d24f 100644
> --- a/sha1_name.c
> +++ b/sha1_name.c
> @@ -547,15 +547,15 @@ static void find_abbrev_len_for_pack(struct packed_git
> *p,
>*/
> mad->init_len = 0;
>
On Tue, Feb 27, 2018 at 02:30:39PM -0800, Junio C Hamano wrote:
> -- >8 --
> From: Derrick Stolee
> Date: Tue, 27 Feb 2018 06:47:04 -0500
> Subject: [PATCH] sha1_name: fix uninitialized memory errors
>
> During abbreviation checks, we navigate to the position within a
>
Jeff King writes:
> Thanks, this looks good to me.
>
> Semi-related, I wondered also at the weird asymmetry in the if-else,
> ...
> So I think the code is right, but the comment is wrong.
-- >8 --
From: Derrick Stolee
Date: Tue, 27 Feb 2018 06:47:04
On Tue, Feb 27, 2018 at 06:47:04AM -0500, Derrick Stolee wrote:
> Peff made an excellent point about the nested if statements. This
> goes back to Christian's original recommendation.
>
> -- >8 --
>
> During abbreviation checks, we navigate to the position within a
> pack-index that an OID
Peff made an excellent point about the nested if statements. This
goes back to Christian's original recommendation.
-- >8 --
During abbreviation checks, we navigate to the position within a
pack-index that an OID would be inserted and check surrounding OIDs
for the maximum matching prefix. This
7 matches
Mail list logo