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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html