Klas Lindberg venit, vidit, dixit 02.10.2008 15:36:
quoted text
> This doesn't seem to work for me. I will soon be in a situation where
> I need to selectively delete commits in such a way that they become
> completely irrecoverable. I.e. it is not enough to revert a commit.
> The *original* commit must be removed. And of course, the repo history
> is too complex to allow for rebasing followed by garbage collection or
> something like that.
> 
> The reason is that we consider opening a repository to external
> participants, but some commits contain stuff that we'd really rather
> not show to anyone else. Making the repository public without loosing
> history would then force us to either
> 
>  1. Recreate every commit in a new repo, sans the offending commits.
> Seems like hard work.
>  2. ?
> 
> Would it be feasible to write a tool that can selectively replace a
> specific commit in the commit DAG, or would that automatically
> invalidate every SHA key for every commit that follows the replaced
> original?

Yes, on the or part: If you change a commit then all commits "after"
that one (in terms of DAG connectedness) will need to be changed: each
contains a "backpointer" (to the parent commit(s)) which is changed.

I'm a bit confused: You rule out rebasing but don't mind recreating a
new repo. So repo size is not a problem, is it?

Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html