Junio C Hamano <gitster@pobox.com> wrote:What about calling it "--keep-unreachable" instead? Can't you just say "o = p->item" here? I can't help but think it would be better to store a "struct object*" here instead of the "const unsigned char *sha1". Both are of type pointer but we only need the struct object* when are working with the in_pack_object elements. Per above just pass the "struct object*" into this function and store that into the array, instead of the sha1. Of course you now need to use "o->sha1" to perform the find_pack_entry_one(). Really? It is not possible for two objects to be placed at the same offset within the same packfile and yet have two different SHA-1 values. The final else condition above is just "return 0". ... If you save the "struct object*" into the in_pack_object (instead of the SHA-1) as I described above you can avoid this second lookup_unknown_object() call when we decide that we do need to pack the object. Otherwise I think it looks quite sane. -- Shawn. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
| Parag Warudkar | BUG: soft lockup - CPU#1 stuck for 15s! [swapper:0] |
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Greg Kroah-Hartman | [PATCH 010/196] Chinese: add translation of Codingstyle |
| Andrew Morton | -mm merge plans for 2.6.23 |
git: | |
| Gerrit Renker | [PATCH 24/37] dccp: Processing Confirm options |
| David Miller | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Alexey Dobriyan | Re: [GIT]: Networking |
| david | Re: iptables very slow after commit 784544739a25c30637397ace5489eeb6e15d7d49 |
