From: Junio C Hamano <junkio@cox.net>
Date: Mon, 16 Jan 2006 23:43:39 GMT
Subject: Re: Cancelling certain commits
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.

> # 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

> ..., 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.