"Eugine Kosenko" [off-list ref] 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
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
2007/5/11, Matthieu Moy [off-list ref]:
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.