Re: Figured out how to get Mozilla into git

From: Junio C Hamano <junkio@cox.net>
Date: Jun 10, 2006, 09:08 UTC
Message-ID: <7vzmglgyz0.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <448A847C.20105@dawes.za.net>

Rogan Dawes <lists@dawes.za.net> writes:

> Here's an idea. How about separating trees and commits from the actual
> blobs (e.g. in separate packs)?

If I remember my numbers correctly, trees for any project with a size that matters contribute nonnegligible amount of the total pack weight. Perhaps 10-25%.

> In this way, the user has a history that will show all of the commit
> messages, and would be able to see _which_ files have changed over
> time e.g. gitk would still work - except for the actual file level
> diff, "git log" should also still work, etc

I suspect it would make a very unpleasant system to use. Sometimes "git diff -p" would show diffs, and other times it mysteriously complain saying that it lacks necessary blobs to do its job. You cannot even run fsck and tell from its output which missing objects are OK (because you chose to create such a sparse repository) and which are real corruption.

A shallow clone with explicit cauterization in grafts file at least would not have that problem. Although the user will still not see the exact same result as what would happen in a full repository, at least we can say "your git log ends at that commit because your copy of the history does not go back beyond that" and the user would understand.