Repo cleanup problem

Repo cleanup problem

[Eugine Kosenko]

I'm sorry, if it is a FAQ.

I use git to track my own changes in a project, i.e, this is a private
(not public) repository. Some time ago I've accidentally committed a
big amount (about of 50M) of crap into the repository, and make a
mature set of commits after this.

For now I'm looking for a way to remove the garbage commit. I've found
a way to remove any commit using git-checkout, git-reset and
git-rebase. But, when I even git-reset the repository to the very
first (root) commit, I see the size is still large enough, i.e., the
crap is still there. I've tried many combinations of git-gc,
git-prune, git-repack, git-prune-packed etc, but the size of the
repository is still the same. The only way I see now is to git-clone
the repository -- the new one is essentially smaller, but needs to
reconstruct the local branches.

Is this (make a clone) the only proper way to clenup a repository, or
there is another magic tool to cleanup the repositories?

Re: Repo cleanup problem

[Matthieu Moy]

"Eugine Kosenko" <eugine.kosenko@gmail.com> writes:

> For now I'm looking for a way to remove the garbage commit.

Branch before the garbage commit. Then, you can use git-rebase to
replay the correct history on top of your new branch. Note that
git-rebase will break merging if you already used merge: it does not
"move" your old commits to your new branch, it instead creates new
commits with the same changes at the old ones, in the new branch.

That's probably what you've done already.

Then, to have git-gc remove the old, bad, history, you need to remove
any reference you have to it: branches and tags. git-branch -d and
perhaps git-tag -d will tell you.

See also git-fsck that can point you to dangling objects, which should
then be removed by git-gc.

gitk --all, on the other hand, will show you the commits to which you
have a reference (and their ancestry).

-- 
Matthieu

Re: Repo cleanup problem

[Karl Hasselström]

On 2007-05-11 10:10:43 +0200, Matthieu Moy wrote:

> Then, to have git-gc remove the old, bad, history, you need to remove
> any reference you have to it: branches and tags. git-branch -d and
> perhaps git-tag -d will tell you.

The reflog is on by default nowadays, which essentially means that
dangling commits won't be pruned for 30 days or something -- unless
you delete the references in the reflog as well. "git reflog expire"
can probably help here.

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle

Re: Repo cleanup problem

[Eugine Kosenko]

2007/5/11, Matthieu Moy <Matthieu.Moy@imag.fr>:
> Branch before the garbage commit. Then, you can use git-rebase to
> replay the correct history on top of your new branch. Note that
> git-rebase will break merging if you already used merge: it does not
> "move" your old commits to your new branch, it instead creates new
> commits with the same changes at the old ones, in the new branch.
>
> That's probably what you've done already.

Almost that. Unfortunately, this simple way causes unexpected
conflicts, so I need also to do sometimes 'git-checkout <tag> .' and
recommit the changes to force the process.