Nicolas Pitre <nico@xxxxxxx> writes:
> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
