Re: [PATCH 5/5] sha1_file: don't re-scan pack directory for null sha1
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Nov 21, 2017, 05:20 UTC
- Message-ID
- <xmqqwp2ki4x8.fsf@gitster.mtv.corp.google.com>
- In-Reply-To
- <20171120203523.c3pt5qi43e24ttqq@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
Show 19 quoted lines
> This is the minimal fix that addresses the performance issues.
> I'd actually have no problem at all declaring that looking up a null
> sha1 is insane, and having the object-lookup routines simply return "no
> such object" without even doing the loose/pack lookup first.
>
> diff --git a/sha1_file.c b/sha1_file.c
> index 8a7c6b7eba..dde0ad101d 100644
> --- a/sha1_file.c
> +++ b/sha1_file.c
> @@ -1180,6 +1180,9 @@ int sha1_object_info_extended(const unsigned char *sha1, struct object_info *oi,
> if (!sha1_loose_object_info(real, oi, flags))
> return 0;
>
> + if (is_null_sha1(sha1))
> + return -1;
> +
> /* Not a loose object; someone else may have just packed it. */
> if (flags & OBJECT_INFO_QUICK) {
> return -1;After queuing this series to an earlier part of 'pu' and resolving a conflict with jh/fsck-promisors topic, I ended up with a code that rejects 0{40} a lot earlier, before we try to see if a pack entry for 0{40} exists, even though the patch that is queued on this topic is more conservative (i.e. the above one).
Perhaps we would want to use the alternate version that declares the 0{40} is a sentinel that signals that there is no such object in this topic---that would give us a consistent semantics without having to adjust jh/fsck-promisors when it becomes ready to be merged.