Re: [QUESTION] Access to a huge GIT repository.

From: Linus Torvalds <torvalds@osdl.org>
Date: Nov 17, 2005, 16:23 UTC
Message-ID: <Pine.LNX.4.64.0511170817480.13959@g5.osdl.org>
In-Reply-To: <cda58cb80511170236p4a7e2baay@mail.gmail.com>

On Thu, 17 Nov 2005, Franck wrote:

Show 5 quoted lines

> 
> Sorry, I forget to tell that I have already tried what you suggested
> at first (except that I did not do a 'git repack -a -d') but it didn't
> work out (and that the reason why I tried the "kill father object"
> thing).

If that didn't work, then you can't kill the father object: it will not only just get rid of one single object, but it will make fsck unhappy that your tree is incomplete.

What you probably _can_ do is to find whatever top-most commit you want (say, the v2.6.0 commit), and use grafting to make that have no parents. Then you can do git-prune to get rid of everything under it.

> Since I forgot the repack thing, I retried again, and it did
> last more than 4 hours to cpmplete all git commands.

Sounds like the original archive was fully unpacked. That really does get very very slow after a while.

>		 After that I run
> gitk --all to check that all old branch's objects have been removed
> but I can see all of them.

Note that if the branches are still there, git prune won't do anything to them (and git repack will pack them all). You need to remove the branches _first_, so that git repack and prune sees that their objects aren't needed.

But yes, if the tree is actually based on some full CVS history and really goes back all the way to 1995, then you can't prune it (since all branches are actually part of the history from the very top), and you'd need to graft away part of it like above.

		Linus