Nicolas Pitre <nico@cam.org> writes:

quoted text
> I'm now starting to wonder if there is a reason for keeping unreachable 
> objects that used to be packed.  Putting --keep-unreachable aside for 
> now, the only way an unreachable object could have entered a pack is if 
> it used to be reachable before through the commit history or reflog.  
> So if they're not reachable anymore, that's most probably because their 
> reflog expired.  So what's the point for keeping them even longer?  
> What's the reasoning that led to the creation of --keep-unreachable in 
> the first place?

I think the logic went like this.

(1) You may have rewound your head since you last repacked; blobs and
    trees in the rewound commit are already packed now.

(2) Now you may be fetching (or somebody else may be pushing) a commit
    that contains such blobs and/or trees, and the fetch or push is small
    enough that it unpacks, but the packed and unreachable ones are not
    unpacked.

(3) But before that fetch or push finishes to update the ref, you can race
    with a "repack -a -d".




--
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