Re: Submodules can't work recursively because Git implements policy?

From: Shawn O. Pearce <spearce@spearce.org>
Date: Apr 6, 2009, 14:51 UTC
Message-ID: <20090406145140.GG23604@spearce.org>
In-Reply-To: <33f4f4d70904060747h72019846gca18255bd71adc22@mail.gmail.com>

Klas Lindberg <klas.lindberg@gmail.com> wrote:

Show 8 quoted lines

> On Mon, Apr 6, 2009 at 3:56 PM, Finn Arne Gangstad <finnag@pvv.org> wrote:
> > Maybe the security concerns could be handled by adding some
> > functionality to (quickly) get rid of unwanted commits?
> 
> Why not simply allow users with write permissions to "pop" revisions
> from the top of the history DAG in a way that actually really deletes
> the them? Or at least moves those commits to a separate, locked down
> DAG that cannot be read by people without write permissions?

What, like a secret shadow repository that you move the objects into?

That could be very expensive in terms of disk IO if those objects
are in large packs.  You'd need to break the pack apart into the
"ok" and "sekret" parts.  Ick.

> But anyway: If I implement support for fetching SHA keys and full
> recursive behaviour in the presence of submodules; would my patches
> automatically be rejected because of the rationale for the current
> behaviour?

See my recent email (like ~10-15 minutes ago). It will be rejected due to the issue that unreachable objects are subjected to GC and you'd easily see your repository delete that data on the next "git gc" invocation. Automatic data destruction is not something that users come to git for.

-- 
Shawn.