On 2006-10-11 00:27, Linus Torvalds wrote:
> Those unreferenced objects are old history that won't be part of any new
> history.
>
> If you create new history, they won't be in the pack.
... because git-repack moves only already-referenced objects to packs
(and once they're referenced a subsequent "git-repack -a -d" won't lose
them). Curiously, this critically depends on Documentation/git-repack
being wrong:
This script is used to combine all objects that do not currently
reside in a "pack", into a pack.
However, this means there is no safe way to create a new pack without
adding all its content as loose objects first.
For example, the following is racy because there's a point where the new
pack is on disk but not yet referenced:
$ git-fetch --keep foo & git-repack -a -d
>> But "git prune" does not GC packs, only loose objects.
>
> Right. And you'd want to repack _and_ prune, but they should be kept
> separate, because one is safe, the other is not.
Ah, semantics.
The request was for removing unreferenced objects ("pruning") in *packs*
while doing the repacking. This turns out to be already implemented
(contrary to the docs) and, as you explained, safe.
Pruning both packed and loose objects while repacking is neither safe
nor requested (and is indeed roughly equivalent to just
"git-repack -a -d; git-prune").
Eran
-
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