Junio C Hamano wrote: > So I do not see how that question is "obvious". The question > obviously pointless and misses the mark by wide margin? The > question makes it obvious that whoever asks it does not understand > how Git works? Shall we all sit and mourn over the fact that I don't understand how Git works, or are you willing to explain it to me? > And of course we do not transfer objects that are not asked for from > or to a repository over pack tranfer. > > Most importantly, it is not about butchering the pack machinery in > such a way that we can create _only_ such "non history traversal" > packs. I asked you a very simple question: what happens when I do "git push"? Instead of answering the question, you butchered the pack machinery to "only" create packs with garbage in them (aka. stripped out the reachability analysis code completely), and blamed me for doing it. Explain it to me in plain English without getting agitated: 1. I'm on my terminal doing various repository operations: constantly creating new objects and moving my refs around to create unreachable objects. I have lots of loose objects. 2. I say "git push". What happens? A reachability analysis is performed on my loose objects, and the ones reachable by the ref I'm sending are packed up and sent over the network. Now, I no longer have any loose objects. 3. After a few days of working, the gc heuristics figure out that I have too much garbage and too many packs; a cleanup is required. The gc --auto which doesn't tolerate fragmentation: it tries to put everything into one large pack. Loop. We're talking about tackling the gc aggression problem in 3. And you propose putting the young objects in a pack without performing reachability analysis: I'm asking how this is going to benefit me; when I say "git push" (or when gc decides to repack), won't I need to explode the young pack into loose objects, do a reachability analysis, and repack anyway? -- 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