Re: removing content from git history

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Feb 21, 2007, 18:13 UTC
Message-ID: <Pine.LNX.4.64.0702211009520.4043@woody.linux-foundation.org>
In-Reply-To: <alpine.LRH.0.82.0702211236180.31945@xanadu.home>

On Wed, 21 Feb 2007, Nicolas Pitre wrote:

> 
> If your goal is to remove content froma repository then the only 
> sensible way is to rewrite history before publishing.  It is pointless 
> to add mechanisms to remove content after it has been distributed.

I'm not entirely in disagreement, but I can see the model where some company wants to make their work available (with the same history as their own internal stuff), but doesn't want to make a single file available for some reason.

So they'd have an external thing that just has the file excised.

Now, arguably, it's a lot better to use a "supermodule" approach for something like this: have two separate git trees, publish the public one, and use an internal supermodule that ties the public and internal trees together.

So supermodules might be a way to solve it in a better (and safer - the "remove objects from the public tree" thing is very error prone, since if you *ever* expose the object by mistake, its now public) way. But I don't think the "filter out objects" thing is necessarily fundamentally flawed as an approach.

			Linus