On 10/7/07, Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: > It should be as easy as git filter-branch and git clone. Yes, a git filter-branch, git clone, AND git gc in the clone avoids all those funny ref editing commands. However, cloning a 5.6GB repo (the size of one of the real repos I'm dealing with) will likely take a long time (and may push me past the limits of disk space), so using other steps to avoid the need to clone actually seems nicer. > > Oh, and git-filter-branch could really use some explanatory note about > > how to actually complete rewriting the history. > > It does what it should do. It is _your_ task to look at refs/original/* > if everything went alright. Then you just delete the checked refs. > > What made your case so cumbersome was that you wanted the big objects out > _now_, instead of having them in for a grace period. BTW this grace > period is in place to help _you_, not the program. (In case you fscked up > and need those objects back.) Sure, I think that's a sane default. And I think it's fine that it should be my task to look at the refs to check that everything worked okay and delete them. But it's nearly impossible to figure out how to do that! _That_ is my complaint. I got multiple misleading or incomplete answers (both on this list and in #git) before getting some working solutions, so this task is obviously far from trivial. I really think that adding instructions about how to check and delete the relevant refs would be a very useful addition to the documentation. Thanks everyone for the help! Elijah - 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
