Re: git-kill: rewrite history removing a commit

Previous thread: [PATCH] tone down the detached head warning by Nicolas Pitre on Wednesday, January 31, 2007 - 12:10 pm. (5 messages)

Next thread: Re: Difficulties in advertising a new branch to git newbies by Junio C Hamano on Wednesday, January 31, 2007 - 1:20 pm. (3 messages)
From: Michael S. Tsirkin
Date: Wednesday, January 31, 2007 - 12:55 pm

Below is a simple script that rewrites history reverting a single commit.
This differs from git-revert in that a commit is completely removed,
and is especially useful before one has published a series of
commits.

Do you find this useful? Comments?
Drop me a line.

#!/bin/sh

commit=$1;
#git-rev-list $commit.. 
revlist=`git-rev-list $commit.. | tac`
git reset --hard $commit
git reset --hard HEAD~1
for rev in $revlist
do
	git-cherry-pick $rev
done
-- 
MST
-

From: Yann Dirson
Date: Wednesday, January 31, 2007 - 1:22 pm

That may be well when no patch depends on the one you kill.  In that
case, it surely requires some work to handfix things.

I'd suggest to use stgit to prepare commits before publication.  Even
if you don't feel the need for it in everyday life, you can have a
one-shot use for this particular problem, by turning your latest
commits into an stgit stack, use stgit facilities to handle posible
conflicts, and turn them into commits again:

The nominal case goes:

  stg init
  stg uncommit -n <ncommits>
  stg float <patch-to-kill>
  stg delete <patch-to-kill>

And if there is any conflict, you can still solve them, decide to
change your plans, get diffs from gitk, etc.

Best regards,
-- 
Yann.
-

From: Catalin Marinas
Date: Thursday, February 1, 2007 - 5:41 am

or "stg pop <patch-to-kill>" instead of 'float'. Recently, I changed the
'pop' command to accept individual patches and patch ranges (for
symmetry with 'push').

-- 
Catalin
-

From: Junio C Hamano
Date: Wednesday, January 31, 2007 - 1:26 pm

"Do you find this useful" is a loaded question.

I do it all the time with git-rebase, so the need to remove a
botched commit from the history and rebuild the remainder is
certainly there, meaning "what your patch does IS useful".

I do it all the time with git-rebase, so I personally do not
need a new tool to do this, meaning "your patch is not useful to
me".

When I find master~8 and master~9 to be undesirable, I would do:

	$ git rebase --onto master~10 master~8

which rebuilds master~7 and onward on top of master~10, thereby
dropping two commits.

-

From: Michael S. Tsirkin
Date: Wednesday, January 31, 2007 - 1:54 pm

That's good to know.
So it turns out I can just rewrite mine as a one-liner:
git-rebase --onto $1~1 $1

Thanks,

-- 
MST
-

Previous thread: [PATCH] tone down the detached head warning by Nicolas Pitre on Wednesday, January 31, 2007 - 12:10 pm. (5 messages)

Next thread: Re: Difficulties in advertising a new branch to git newbies by Junio C Hamano on Wednesday, January 31, 2007 - 1:20 pm. (3 messages)