threads / discuss / 8088

kernel cherry UN-picking?

Subject: kernel cherry UN-picking?

## tl;dr

9 messages between May 11, 2007 and May 15, 2007.

replies: 8people: 5as markdown or json

Jeff Garzik· May 11, 2007, 21:31 UTC · lore

So, I merge the next batch of net driver patches. After I merge a PPP patch, deep in the pile-o-patches, Andrew says "I shouldn't have sent that to you, don't apply it" ;-)

Right now, my process for reversing this damage is to start over: create a new branch, manually double-click the mouse on each commit in the "damaged" branch, and git-cherrypick it. Very, very time consuming when you have more than a couple commits.

Is there a better way? Is there any way to say "cherrypick all commits except <these>"?

	Jeff
Andrew Morton· May 11, 2007, 21:55 UTC · re: Jeff Garzik · lore

Re: kernel cherry UN-picking?

On Fri, 11 May 2007 17:31:14 -0400 Jeff Garzik <jeff@garzik.org> wrote:

> So, I merge the next batch of net driver patches.  After I merge a PPP 
> patch, deep in the pile-o-patches, Andrew says "I shouldn't have sent 
> that to you, don't apply it"  ;-)
I'm bad.
Show 7 quoted lines
> Right now, my process for reversing this damage is to start over: 
> create a new branch, manually double-click the mouse on each commit in 
> the "damaged" branch, and git-cherrypick it.  Very, very time consuming 
> when you have more than a couple commits.
> 
> Is there a better way?
> Is there any way to say "cherrypick all commits except <these>"?

Let me refactor your question more usefully. What we want is quilt-export and quilt-import. And I really mean that: commands called git-quilt-export and git-quilt-import.

coz then, your problem becomes
	git-quilt-export
	<delete one line from the series file>
	git-quilt-import

Because git-quilt-export and git-quilt-import would be useful for lots of other things.

Jeff Garzik· May 11, 2007, 21:56 UTC · re: Andrew Morton · lore

Re: kernel cherry UN-picking?

Andrew Morton wrote:
Show 8 quoted lines
> On Fri, 11 May 2007 17:31:14 -0400
> Jeff Garzik <jeff@garzik.org> wrote:
> 
>> So, I merge the next batch of net driver patches.  After I merge a PPP 
>> patch, deep in the pile-o-patches, Andrew says "I shouldn't have sent 
>> that to you, don't apply it"  ;-)
> 
> I'm bad.
You're just an example.  This is a problem guaranteed to appear...
Show 17 quoted lines
>> Right now, my process for reversing this damage is to start over: 
>> create a new branch, manually double-click the mouse on each commit in 
>> the "damaged" branch, and git-cherrypick it.  Very, very time consuming 
>> when you have more than a couple commits.
>>
>> Is there a better way?
>> Is there any way to say "cherrypick all commits except <these>"?
> 
> Let me refactor your question more usefully.  What we want is quilt-export
> and quilt-import.  And I really mean that: commands called git-quilt-export
> and git-quilt-import.
> 
> coz then, your problem becomes
> 
> 	git-quilt-export
> 	<delete one line from the series file>
> 	git-quilt-import
Doesn't work when I've pulled git trees from Linville...
	Jeff
Josef Sipek· May 15, 2007, 02:39 UTC · re: Andrew Morton · lore

Re: kernel cherry UN-picking?

On Fri, May 11, 2007 at 02:55:09PM -0700, Andrew Morton wrote:
Show 26 quoted lines
> On Fri, 11 May 2007 17:31:14 -0400
> Jeff Garzik <jeff@garzik.org> wrote:
> 
> > So, I merge the next batch of net driver patches.  After I merge a PPP 
> > patch, deep in the pile-o-patches, Andrew says "I shouldn't have sent 
> > that to you, don't apply it"  ;-)
> 
> I'm bad.
> 
> > Right now, my process for reversing this damage is to start over: 
> > create a new branch, manually double-click the mouse on each commit in 
> > the "damaged" branch, and git-cherrypick it.  Very, very time consuming 
> > when you have more than a couple commits.
> > 
> > Is there a better way?
> > Is there any way to say "cherrypick all commits except <these>"?
> 
> Let me refactor your question more usefully.  What we want is quilt-export
> and quilt-import.  And I really mean that: commands called git-quilt-export
> and git-quilt-import.
> 
> coz then, your problem becomes
> 
> 	git-quilt-export
> 	<delete one line from the series file>
> 	git-quilt-import
<shameless plug>
You can use Guilt:
$ guilt-init
$ guilt-import-commit <the bad commit hash>^..
$ $EDITOR .git/patches/$branch/series
	# remove the offending line from the series file
$ guilt-push -a
$ rm -rf .git/patches/$branch
</shameless plug>
Josef "Jeff" Sipek.
-- 
All science is either physics or stamp collecting.
		- Ernest Rutherford
Junio C Hamano· May 11, 2007, 21:56 UTC · re: Jeff Garzik · lore

Re: kernel cherry UN-picking?

Jeff Garzik <jeff@garzik.org> writes:
Show 8 quoted lines
> So, I merge the next batch of net driver patches.  After I merge a PPP
> patch, deep in the pile-o-patches, Andrew says "I shouldn't have sent
> that to you, don't apply it"  ;-)
>
> Right now, my process for reversing this damage is to start over:
> create a new branch, manually double-click the mouse on each commit in
> the "damaged" branch, and git-cherrypick it.  Very, very time
> consuming when you have more than a couple commits.

Do the commits on the branch being rebuilt form a single strand of pearls without any merges? If that is the case, what I would do is:

	git heckout thatbranch
	git format-patch -o ./+outdir linus
        rm ./+outdir/0XXX-that-unwanted-patch.patch
        git reset --hard linus
        git am ./+outdir/????-*.patch
Junio C Hamano· May 11, 2007, 22:09 UTC · re: Junio C Hamano · lore

Re: kernel cherry UN-picking?

Junio C Hamano <junkio@cox.net> writes:
Show 20 quoted lines
> Jeff Garzik <jeff@garzik.org> writes:
>
>> So, I merge the next batch of net driver patches.  After I merge a PPP
>> patch, deep in the pile-o-patches, Andrew says "I shouldn't have sent
>> that to you, don't apply it"  ;-)
>>
>> Right now, my process for reversing this damage is to start over:
>> create a new branch, manually double-click the mouse on each commit in
>> the "damaged" branch, and git-cherrypick it.  Very, very time
>> consuming when you have more than a couple commits.
>
> Do the commits on the branch being rebuilt form a single strand
> of pearls without any merges?  If that is the case, what I would
> do is:
>
> 	git heckout thatbranch
> 	git format-patch -o ./+outdir linus
>         rm ./+outdir/0XXX-that-unwanted-patch.patch
>         git reset --hard linus
>         git am ./+outdir/????-*.patch

Ok, you answered that your branch involves a merge from Linville tree.

You would need to segment things then.

Suppose you have something like this (you may have more than one such merge but the principle is the same):

  U---o---o---o---M---x---o---o---o---T
                 /
   Linville o---o

Up to 'U' you have already sent upstream and no need for resending. 'M' is merge with Linville tree. 'x' is the bad one, and 'o' are good ones. 'T' is the tip of your net driver branch.

First find out 'x'.  Then
        git format-patch -o ./outdir x..T

would format everything starting from (but excluding) 'x' up to 'T'.

Then
        git reset --hard x^
        git am ./outdir/*.patch
would rebuild:
  U---o---o---o---M---x---o'--o'--o'--T'
                 /
   Linville o---o

A variant that needs "segmenting" is if the bad one is before the merge, like this:

  U---o---x---b---M---o---o---o---o---T
                 /
   Linville o---a

First you need to note 'a' (tip of Linville you pulled) and 'b' (tip of you before you pulled from Linville). Then:

        git format-patch -o ./outdir-1 x..b
        git format-patch -o ./outdir-2 M..T
        git reset --hard x^
        git am ./outdir-1/*.patch
would give you this:
  U---o-------b'
                 
   Linville o---a

and leave you at b (rebased not to contain the bad one). Then you redo the Linville merge:

  U---o-------b'--M'
                 /
   Linville o---a
And finally apply the rest:
        git am ./outdir-2/*.patch
to arrive at:
  U---o-------b'--M'--o'--o'--o'--o'--T'
                 /
   Linville o---a
Junio C Hamano· May 11, 2007, 22:11 UTC · re: Junio C Hamano · lore

Re: kernel cherry UN-picking?

Junio C Hamano <junkio@cox.net> writes:
Show 29 quoted lines
> Suppose you have something like this (you may have more than one
> such merge but the principle is the same):
>
>   U---o---o---o---M---x---o---o---o---T
>                  /
>    Linville o---o
>
> Up to 'U' you have already sent upstream and no need for
> resending.  'M' is merge with Linville tree.  'x' is the bad
> one, and 'o' are good ones.  'T' is the tip of your net driver
> branch.
>
> First find out 'x'.  Then
>
>         git format-patch -o ./outdir x..T
>
> would format everything starting from (but excluding) 'x' up to
> 'T'.
>
> Then
>
>         git reset --hard x^
>         git am ./outdir/*.patch
>
> would rebuild:
>
>   U---o---o---o---M---x---o'--o'--o'--T'
>                  /
>    Linville o---o
Correction.  This would rebuild:
    U---o---o---o---M-------o'--o'--o'--T'
                   /
     Linville o---o
as if 'x' did not happen.
Jan Harkes· May 12, 2007, 13:39 UTC · re: Junio C Hamano · lore

Re: kernel cherry UN-picking?

On Fri, May 11, 2007 at 03:09:14PM -0700, Junio C Hamano wrote:
Show 11 quoted lines
> Suppose you have something like this (you may have more than one
> such merge but the principle is the same):
> 
>   U---o---o---o---M---x---o---o---o---T
>                  /
>    Linville o---o
> 
> Up to 'U' you have already sent upstream and no need for
> resending.  'M' is merge with Linville tree.  'x' is the bad
> one, and 'o' are good ones.  'T' is the tip of your net driver
> branch.

There are even more ways to fix this up, they both start with identifying the commit 'y' that was committed after 'x',

    git rebase --onto x^ y T
The other solution is to use .git/info/grafts,
    Add a line with the sha1 of 'y' with the parents of 'x'. You can
    visually inspect with gitk if it looks right and then use a script
    that rewrites the history. Either cg-admin-rewrite or the one I
    posted to the list a while ago.

The history rewriting solution will work even if 'x' was introduced before the merge commit.

Jan
Jan Harkes· May 12, 2007, 14:01 UTC · re: Jan Harkes · lore

Re: kernel cherry UN-picking?

On Sat, May 12, 2007 at 09:39:51AM -0400, Jan Harkes wrote:
Show 27 quoted lines
> On Fri, May 11, 2007 at 03:09:14PM -0700, Junio C Hamano wrote:
> > Suppose you have something like this (you may have more than one
> > such merge but the principle is the same):
> > 
> >   U---o---o---o---M---x---o---o---o---T
> >                  /
> >    Linville o---o
> > 
> > Up to 'U' you have already sent upstream and no need for
> > resending.  'M' is merge with Linville tree.  'x' is the bad
> > one, and 'o' are good ones.  'T' is the tip of your net driver
> > branch.
> 
> There are even more ways to fix this up, they both start with
> identifying the commit 'y' that was committed after 'x',
> 
>     git rebase --onto x^ y T
> 
> The other solution is to use .git/info/grafts,
> 
>     Add a line with the sha1 of 'y' with the parents of 'x'. You can
>     visually inspect with gitk if it looks right and then use a script
>     that rewrites the history. Either cg-admin-rewrite or the one I
>     posted to the list a while ago.
> 
> The history rewriting solution will work even if 'x' was introduced
> before the merge commit.

My brain must be fried. history rewriting is not a good solution here. Although it removes the commit message, it would leave the bad change around because it leaves the actual trees intact.

Jan

← back to recent threads