* git-kill: rewrite history removing a commit @ 2007-01-31 19:55 Michael S. Tsirkin 2007-01-31 20:22 ` Yann Dirson 2007-01-31 20:26 ` Junio C Hamano 0 siblings, 2 replies; 5+ messages in thread From: Michael S. Tsirkin @ 2007-01-31 19:55 UTC (permalink / raw) To: Junio C Hamano; +Cc: git 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: git-kill: rewrite history removing a commit 2007-01-31 19:55 git-kill: rewrite history removing a commit Michael S. Tsirkin @ 2007-01-31 20:22 ` Yann Dirson 2007-02-01 12:41 ` Catalin Marinas 2007-01-31 20:26 ` Junio C Hamano 1 sibling, 1 reply; 5+ messages in thread From: Yann Dirson @ 2007-01-31 20:22 UTC (permalink / raw) To: Michael S. Tsirkin; +Cc: Junio C Hamano, git On Wed, Jan 31, 2007 at 09:55:33PM +0200, Michael S. Tsirkin wrote: > 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? 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. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: git-kill: rewrite history removing a commit 2007-01-31 20:22 ` Yann Dirson @ 2007-02-01 12:41 ` Catalin Marinas 0 siblings, 0 replies; 5+ messages in thread From: Catalin Marinas @ 2007-02-01 12:41 UTC (permalink / raw) To: Yann Dirson; +Cc: Michael S. Tsirkin, Junio C Hamano, git Yann Dirson <ydirson@altern•org> wrote: > 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> 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: git-kill: rewrite history removing a commit 2007-01-31 19:55 git-kill: rewrite history removing a commit Michael S. Tsirkin 2007-01-31 20:22 ` Yann Dirson @ 2007-01-31 20:26 ` Junio C Hamano 2007-01-31 20:54 ` Michael S. Tsirkin 1 sibling, 1 reply; 5+ messages in thread From: Junio C Hamano @ 2007-01-31 20:26 UTC (permalink / raw) To: Michael S. Tsirkin; +Cc: git "Michael S. Tsirkin" <mst@mellanox•co.il> writes: > 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. "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. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: git-kill: rewrite history removing a commit 2007-01-31 20:26 ` Junio C Hamano @ 2007-01-31 20:54 ` Michael S. Tsirkin 0 siblings, 0 replies; 5+ messages in thread From: Michael S. Tsirkin @ 2007-01-31 20:54 UTC (permalink / raw) To: Junio C Hamano; +Cc: git > 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. 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2007-02-01 12:41 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2007-01-31 19:55 git-kill: rewrite history removing a commit Michael S. Tsirkin 2007-01-31 20:22 ` Yann Dirson 2007-02-01 12:41 ` Catalin Marinas 2007-01-31 20:26 ` Junio C Hamano 2007-01-31 20:54 ` Michael S. Tsirkin
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox