Repo size is a problem too, actually. A solution to both problems seemed to be to use git-filter-branch to create a new repo by filtering out all the unwanted files. The astonishing result was that, for the subdirectory I tried it on, 90% or so of the commits on that subdirectory just disappeared. It didn't look right at all. Although I can't say for sure exactly what I did with filter-branch, I would appreciate some guidance for using it. It basically seemed to do exactly what I wanted (recreate the repo, minus some explicit stuff, with history intact otherwise), except the result looked crazy. /Klas On Thu, Oct 2, 2008 at 4:02 PM, Jakub Narebski <jnareb@xxxxxxxxx> wrote: > "Klas Lindberg" <klas.lindberg@xxxxxxxxx> writes: > >> 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. > [...] > >> 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? > > It would invalidate SHA1 for every commit after first rewritten. > There are two tools which you can use to rewrite large parts of > history automatically: git-filter-branch, and git-fast-export + > git-fast-import. > > HTH > -- > Jakub Narebski > Poland > ShadeHawk on #git > -- 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
