From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 83B38982 for ; Fri, 15 Jul 2016 12:44:56 +0000 (UTC) Received: from mail-it0-f66.google.com (mail-it0-f66.google.com [209.85.214.66]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D29B41F6 for ; Fri, 15 Jul 2016 12:44:55 +0000 (UTC) Received: by mail-it0-f66.google.com with SMTP id d65so1149904ith.0 for ; Fri, 15 Jul 2016 05:44:55 -0700 (PDT) MIME-Version: 1.0 Sender: geert.uytterhoeven@gmail.com In-Reply-To: <1468586157.2440.2.camel@HansenPartnership.com> References: <718BE1FD-6169-4205-A905-53F997D5943A@primarydata.com> <5785C80F.4030707@linaro.org> <20160713090739.GA18037@kroah.com> <20160713143447.GH9976@sirena.org.uk> <20160714031753.GA28722@kroah.com> <20160714100603.GJ9976@sirena.org.uk> <20160715002239.GA31603@kroah.com> <5788337F.8000500@roeck-us.net> <20160715014103.GA5791@kroah.com> <578850EB.3090109@roeck-us.net> <20160715042938.GA5527@kroah.com> <874m7rcus8.fsf@notabene.neil.brown.name> <1468564337.2420.37.camel@HansenPartnership.com> <1468586157.2440.2.camel@HansenPartnership.com> From: Geert Uytterhoeven Date: Fri, 15 Jul 2016 14:44:54 +0200 Message-ID: To: James Bottomley Content-Type: text/plain; charset=UTF-8 Cc: Trond Myklebust , "ksummit-discuss@lists.linuxfoundation.org" Subject: Re: [Ksummit-discuss] [CORE TOPIC] kernel unit testing List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Hi James, On Fri, Jul 15, 2016 at 2:35 PM, James Bottomley wrote: > On Fri, 2016-07-15 at 13:05 +0200, Geert Uytterhoeven wrote: >> On Fri, Jul 15, 2016 at 8:32 AM, James Bottomley >> wrote: >> > On Fri, 2016-07-15 at 15:52 +1000, NeilBrown wrote: >> > > I do find quilt useful when backporting a series of patches so >> > > that I >> > > can resolve the conflicts on each patch individually and move >> > > backwards and forwards through the list of patches. I don't >> > > think >> > > git has an easy way to store a branch of patches-that-I-need-to >> > > -apply >> > > and to then give me one at a time, removing them from the branch. >> > > I >> > > could use 'stgit' for that if necessary, though it is very >> > > tempting >> > > to write something that is better integrated with git. >> > >> > Git cherry and git cherry-pick can do this. Git cherry-pick can >> > take a >> > range of patches to apply, so you can select a bunch of patches to >> > backport or otherwise move all at once. Git cherry can tell you >> > (to >> > within an approximation, since it uses matching) what patches are >> > common between two branches even if they have differing commit ids. >> >> ... which is basically the same as creating a new branch matching >> your old private tree, and rebasing that --onto the new upstream. > > You mean using rebase -i so you can pick the commits? Yes, it sort of No, without the -i. > is but there's the extra step of firing up the editor and selecting > them. If you have the ids handy, you can feed them directly into git > cherry-pick without needing the extra edit and select step (which also > makes it scriptable). If it's about passing a range of patches to git cherry-pick, you could the same operation using one rebase command. > You still need git cherry to see what is common and what you added (or > didn't add). git rebase already does the same filtering internally. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds