On 10/7/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
quoted text
> 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.

quoted text
> > 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html