Re: Cancelling certain commits

From: Junio C Hamano <junkio@cox.net>
Date: Jan 16, 2006, 23:43 UTC
Message-ID: <7vvewjlowk.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <43CBAC0B.3020104@op5.se>

Andreas Ericsson <ae@op5.se> writes:

 ... (all the good stuff not repeated).

As a general rule, first of all, make sure that this kind of "cleaning up the history" can be done only before you make your history available to others, and not after.

Show 8 quoted lines

> # make sure "git status" doesn't show any changes
>
> $ git branch anchor # to make a safe point to reset to if things go bad
> $ git reset --hard HEAD~7 # undo commits 3 - 10
> # replay commits 4, 5, 6, 8, 9
> $ for i in 6 5 4 2 1; do git cherry-pick -r anchor~$i || break; done
> # replay commit 10
> $ git cherry-pick -r anchor

I think "6 5 4 2 1 0" would be sweeter.  rev~0 == rev

Show 8 quoted lines

> ..., and never *ever*
> do
>
> $ git prune
>
> on a repo where you're juggling loose commits like this (although that
> should actually be safe when you create 'anchor' as a branch rather
> than as a tag, which Junio usually recommends).

Sorry, I do not understand this part. tags and branch heads are used in the same way to determine what objects to protect from "prune", so I thought there was no difference from the safety point of view between the anchor being a branch or a tag.