Klas Lindberg venit, vidit, dixit 02.10.2008 15:36: > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
