# kernel cherry UN-picking? 9 messages from 2007-05-11 to 2007-05-15. Participants: Jeff Garzik, Andrew Morton, Junio C Hamano, Jan Harkes, Josef Sipek. Thread: https://gitlist.dev/t/8088 ## Jeff Garzik, 2007-05-11 21:31 Subject: kernel cherry UN-picking? Message-ID: <4644E0A2.90008@garzik.org> URL: https://gitlist.dev/e/4644E0A2.90008%40garzik.org ``` 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 "? Jeff ``` ## Andrew Morton, 2007-05-11 21:55 Subject: Re: kernel cherry UN-picking? Message-ID: <20070511145509.09f3c354.akpm@linux-foundation.org> URL: https://gitlist.dev/e/20070511145509.09f3c354.akpm%40linux-foundation.org In-Reply-To: <4644E0A2.90008@garzik.org> ``` On Fri, 11 May 2007 17:31:14 -0400 Jeff Garzik 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 "? 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 git-quilt-import Because git-quilt-export and git-quilt-import would be useful for lots of other things. ``` ## Junio C Hamano, 2007-05-11 21:56 Subject: Re: kernel cherry UN-picking? Message-ID: <7vhcqj9g8r.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vhcqj9g8r.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <4644E0A2.90008@garzik.org> ``` Jeff Garzik 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 ``` ## Jeff Garzik, 2007-05-11 21:56 Subject: Re: kernel cherry UN-picking? Message-ID: <4644E6AA.9050908@garzik.org> URL: https://gitlist.dev/e/4644E6AA.9050908%40garzik.org In-Reply-To: <20070511145509.09f3c354.akpm@linux-foundation.org> ``` Andrew Morton wrote: > On Fri, 11 May 2007 17:31:14 -0400 > Jeff Garzik 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 "? > > 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 > > git-quilt-import Doesn't work when I've pulled git trees from Linville... Jeff ``` ## Junio C Hamano, 2007-05-11 22:09 Subject: Re: kernel cherry UN-picking? Message-ID: <7vbqgr9fn9.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vbqgr9fn9.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <7vhcqj9g8r.fsf@assigned-by-dhcp.cox.net> ``` Junio C Hamano writes: > Jeff Garzik 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, 2007-05-11 22:11 Subject: Re: kernel cherry UN-picking? Message-ID: <7v7irf9fjc.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7v7irf9fjc.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <7vbqgr9fn9.fsf@assigned-by-dhcp.cox.net> ``` Junio C Hamano 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. ``` ## Jan Harkes, 2007-05-12 13:39 Subject: Re: kernel cherry UN-picking? Message-ID: <20070512133951.GE12121@delft.aura.cs.cmu.edu> URL: https://gitlist.dev/e/20070512133951.GE12121%40delft.aura.cs.cmu.edu In-Reply-To: <7vbqgr9fn9.fsf@assigned-by-dhcp.cox.net> ``` 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 ``` ## Jan Harkes, 2007-05-12 14:01 Subject: Re: kernel cherry UN-picking? Message-ID: <20070512140117.GF12121@delft.aura.cs.cmu.edu> URL: https://gitlist.dev/e/20070512140117.GF12121%40delft.aura.cs.cmu.edu In-Reply-To: <20070512133951.GE12121@delft.aura.cs.cmu.edu> ``` 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 ``` ## Josef Sipek, 2007-05-15 02:39 Subject: Re: kernel cherry UN-picking? Message-ID: <20070515023941.GA20340@filer.fsl.cs.sunysb.edu> URL: https://gitlist.dev/e/20070515023941.GA20340%40filer.fsl.cs.sunysb.edu In-Reply-To: <20070511145509.09f3c354.akpm@linux-foundation.org> ``` On Fri, May 11, 2007 at 02:55:09PM -0700, Andrew Morton wrote: > On Fri, 11 May 2007 17:31:14 -0400 > Jeff Garzik 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 "? > > 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 > > git-quilt-import You can use Guilt: $ guilt-init $ guilt-import-commit ^.. $ $EDITOR .git/patches/$branch/series # remove the offending line from the series file $ guilt-push -a $ rm -rf .git/patches/$branch Josef "Jeff" Sipek. -- All science is either physics or stamp collecting. - Ernest Rutherford ```