Re: removing content from git history

From: Shawn O. Pearce <spearce@spearce.org>
Date: Feb 21, 2007, 21:00 UTC
Message-ID: <20070221210045.GB26525@spearce.org>
In-Reply-To: <Pine.LNX.4.64.0702210934470.4043@woody.linux-foundation.org>

Linus Torvalds <torvalds@linux-foundation.org> wrote:

Show 7 quoted lines

> Anyway, git-convert-objects does kind of give you a starting point. It 
> should be fixed to use "git-fast-import" or repack once in a while (so 
> that it doesn't leave tons and tons of unpacked objects), and it should be 
> fixed to fix up any commit messages that mention SHA1's that it has 
> already converted to something else, but it seems to still work. It would 
> not be impossible at all to extend the tree-rewriting logic to remove some 
> file or a particular SHA1 object you want to replace.

One idea Junio and I kicked around on #git a short while ago was to arrange for a pipe between the current Git process and git-fast-import, where the pipe was used from within write_sha1_file() rather than creating the loose object.

This way an existing process like git-apply or git-convert-objects could easily spew hundreds of thousands of objects without needing to worry about repacking in the middle; nor would we need to worry about the complexity of trying to disentagle the multiobject packing parts of fast-import into some sort of library.

Obviously this is only a good idea if we are going to be making enough objects to warrant using a packfile; small 10-20 bursts of objects from a git-apply doesn't really justify a packfile. But applying 100s of patches in a row might, if we could keep them all fed through the same git-fast-import backend (and thus into the same packfile).

-- 
Shawn.