Jeff King <peff@peff.net> writes:It probably would not matter for sane repositories, but with thousands of refs, strlen() and prefixcmp() may start to hurt: struct ref *ref; int reflen; const char *msg = strchr(line, ' '); if (!msg) return NULL; reflen = msg - line; msg++; for (ref = refs; ref; ref = ref->next) { if (strncmp(line, ref->name, reflen) || line[reflen] != ' ') continue; ... return ref->next; } return NULL; but the "hint" optimization probably make the above micro-optimization irrelevant. It is preferred to have a multi-line comment like this: /* * A return value of -1 ... * ... * ... couldn't even get that far. */ Clever... taking advantage of the order receive-pack reports to optimize. Before receive_status() is called, can the refs already have the error status and string set? Hmm. When we did not receive status, we cannot tell what succeeded or failed, but what we _can_ tell the user is which refs we attempted to push. I wonder if robbing that information from the user with this "return -1" is a good idea. Perhaps we would instead want to set the status of all the refs to error and call print_push_status() anyway? I dunno. - 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
| Andrew Morton | -mm merge plans for 2.6.23 |
| Greg Kroah-Hartman | [PATCH 004/196] Chinese: add translation of SubmittingPatches |
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Gabriel C | Re: [Announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS] |
git: | |
| Gerrit Renker | [PATCH 03/37] dccp: List management for new feature negotiation |
| David Miller | [GIT]: Networking |
| Thomas Jarosch | Re: TCP connection stalls under 2.6.24.7 |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
