Junio C Hamano wrote: > it is > not a problem for the pack that consolidates young objects into a > single pack to contain some unreachable crufts. So far, we have never considered putting unreachable objects in packs. Let me ask the obvious question first: what happens when I push? Do I pack up all the loose objects quickly (without bothering about reachability) and send unreachable cruft to the server? Who is ultimately going to clean up this cruft, and when? > Note that *1* is an assumption. I do not know offhand if such a > "consolidate young objects quickly into one to keep the number of > packs small" strategy is an overall win. The way I see it, you're just delaying the reachability analysis beyond the usual pack-time. The whole point of separating out loose objects from packfiles was to not make the user wait everytime she does common repository operations locally: delay the reachability analysis and compression (aka. packing) until a network operation kicks in. To see if introducing another stage is an overall win, think about what the bottlenecks are: in network operations, it's always the data being sent over. If I understand correctly, during a network transaction, there's very minimal computation where the server-client just quickly tell each other where their refs are: therefore, it's trivial to figure out what's missing and pack that up to send it over. The strategy of including unreachable cruft in these packs might make sense from the point of view of a local gc, but will ultimately slow down network operations, no? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html