From: Lukas Sandström Date: Sat, 19 Nov 2005 12:45:27 GMT Subject: Re: [QUESTION] Access to a huge GIT repository. Message-ID: <437F1E67.8020302@etek.chalmers.se> In-Reply-To: Franck wrote: > 2005/11/17, Linus Torvalds : > >>>On Thu, 17 Nov 2005, Franck wrote: >>> >>>ok that's what I was trying to do by killing the parent object. Now >>>when looking a the graph using gitk all old objects have been removed. >>>But I'm suprised because the git repository is the same size as it was >>>before pruning all old objects. Can you explain why ? >> >>make sure you re-pack if it was packed. "git prune" will not remove packs >>at all, so.. >> > > > I just looked at git-prune script and it seems to remove unreachable > objects only in .git/objects/[0-9a-f][0-9a-f] directories, not in pack > files. > > Then by running git-repack -a -d, I build a new small pack that > contains only latest objects, but then the script runs > git-redundant-pack script which erases the new small one since all its > objects are included in the old big one. Is that correct ? If so > git-redundant-pack script could return the oldest redundant ? > > Thanks > -- > Franck The reason the old pack is kept instead of the new one is that it is a proper superset of the new one. The "git-repack -a -d" case is fixed in Junios master, and I have sent out a patch which lets you pipe git-fsck-objects --full --unreachable to git-pack-redundant in the other cases, so the problem should hopefully be resolved shortly. /Lukas