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? BR / Klas On Fri, Sep 19, 2008 at 11:16 AM, Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> wrote: > Steven Grimm venit, vidit, dixit 19.09.2008 01:41: >> I maintain a shared repository a bunch of my coworkers push to for >> code reviews. It has accumulated a lot of packfiles, so I want to >> shrink it down a bit, but there's a problem: >> >> % git repack -A -d >> Counting objects: ... >> error: Could not read 125bf191b65189aaec7a6aa24ff26460d141d587 >> fatal: bad tree object 125bf191b65189aaec7a6aa24ff26460d141d587 >> >> "git fsck" confirms that the tree object is missing: >> >> % git fsck >> broken link from commit 1b2f0595bb4a6c2e17ca43a9cc41feec88c72a47 >> to tree 125bf191b65189aaec7a6aa24ff26460d141d587 >> ... >> missing tree 125bf191b65189aaec7a6aa24ff26460d141d587 >> >> This is a dangling commit, but that's fine; for this particular >> repository we actually *want* lots of dangling commits since they >> represent the history of people's code review requests. (Hence me >> running git-repack with -A instead of -a.) >> >> Given that it's dangling, it seems like it'd be safe to just remove >> entirely (we lose that little bit of code-review history but we've >> lost it already anyway with the tree object missing). But I'm not sure >> how to do it. Is it possible to delete a commit object, and if so, how? >> >> I don't know how the corruption happened in the first place. There was >> a short time at one point where the permissions on the object >> directories were inconsistent, so it's possible someone pushed during >> that period and managed to create the commit object file in .git/ >> objects but didn't have permission to create the tree object. That's >> just speculation on my part, though. This is the only corrupt object >> in the repository according to git-fsck, so at this point I just want >> to know how to get rid of it so I can do the repack. > > git prune should delete dangling commits. Is that commit already in a > pack? Then the -f option to repack may help. > > 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 > -- 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
