# Repo cleanup problem 4 messages from 2007-05-11 to 2007-05-11. Participants: Eugine Kosenko, Matthieu Moy, Karl Hasselström. Thread: https://gitlist.dev/t/8080 ## Eugine Kosenko, 2007-05-11 08:03 Subject: Repo cleanup problem Message-ID: <9909dee80705110103h5b848490m296c001beecfa1f1@mail.gmail.com> URL: https://gitlist.dev/e/9909dee80705110103h5b848490m296c001beecfa1f1%40mail.gmail.com ``` 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? ``` ## Matthieu Moy, 2007-05-11 08:10 Subject: Re: Repo cleanup problem Message-ID: URL: https://gitlist.dev/e/vpqveezhjb0.fsf%40bauges.imag.fr In-Reply-To: <9909dee80705110103h5b848490m296c001beecfa1f1@mail.gmail.com> ``` "Eugine Kosenko" 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 ``` ## Karl Hasselström, 2007-05-11 08:19 Subject: Re: Repo cleanup problem Message-ID: <20070511081906.GA21093@diana.vm.bytemark.co.uk> URL: https://gitlist.dev/e/20070511081906.GA21093%40diana.vm.bytemark.co.uk In-Reply-To: ``` 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 ``` ## Eugine Kosenko, 2007-05-11 09:32 Subject: Re: Repo cleanup problem Message-ID: <9909dee80705110232m5ef56517i542728ef8657971e@mail.gmail.com> URL: https://gitlist.dev/e/9909dee80705110232m5ef56517i542728ef8657971e%40mail.gmail.com In-Reply-To: ``` 2007/5/11, Matthieu Moy : > 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 .' and recommit the changes to force the process. ```