kernel cherry UN-picking?

kernel cherry UN-picking?

[Jeff Garzik]

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

Re: kernel cherry UN-picking?

[Andrew Morton]

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


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

Re: kernel cherry UN-picking?

[Jeff Garzik]

Andrew Morton wrote:
> 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...


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

Re: kernel cherry UN-picking?

[Josef Sipek]

On Fri, May 11, 2007 at 02:55:09PM -0700, Andrew Morton wrote:
> 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

Re: kernel cherry UN-picking?

[Junio C Hamano]

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

Re: kernel cherry UN-picking?

[Junio C Hamano]

Junio C Hamano <junkio@cox.net> writes:

> 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

Re: kernel cherry UN-picking?

[Junio C Hamano]

Junio C Hamano <junkio@cox.net> writes:

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

Re: kernel cherry UN-picking?

[Jan Harkes]

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.

Jan

Re: kernel cherry UN-picking?

[Jan Harkes]

On Sat, May 12, 2007 at 09:39:51AM -0400, Jan Harkes wrote:
> 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