From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Lyl2G-00018r-Ag for qemu-devel@nongnu.org; Tue, 28 Apr 2009 06:59:36 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Lyl2B-00017w-Mp for qemu-devel@nongnu.org; Tue, 28 Apr 2009 06:59:35 -0400 Received: from [199.232.76.173] (port=59843 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Lyl2B-00017s-Gu for qemu-devel@nongnu.org; Tue, 28 Apr 2009 06:59:31 -0400 Received: from mx2.redhat.com ([66.187.237.31]:53677) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Lyl2B-0000sm-2J for qemu-devel@nongnu.org; Tue, 28 Apr 2009 06:59:31 -0400 Message-ID: <49F6E151.8030507@redhat.com> Date: Tue, 28 Apr 2009 12:58:25 +0200 From: Kevin Wolf MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: updating git tree References: <761ea48b0904272354w3267b367hb62ee873b5e50a29@mail.gmail.com> <200904281049.54617.Christoph.Egger@amd.com> <49F6CE81.7040809@siemens.com> <49F6D493.9050806@redhat.com> <49F6D880.1060409@siemens.com> <49F6DA48.4070000@redhat.com> <49F6DEFB.9090106@siemens.com> In-Reply-To: <49F6DEFB.9090106@siemens.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Laurent Desnogues , Christoph Egger , "C.W. Betts" , qemu-devel@nongnu.org Jan Kiszka schrieb: > Kevin Wolf wrote: >> Jan Kiszka schrieb: >>> Kevin Wolf wrote: >>>> Jan Kiszka schrieb: >>>>> If you have non-trivial changes pending, probably in multiple commits, I >>>>> can only recommend using stgit (or guilt) to compensate the missing >>>>> patch queue feature of git. It allows you to easily navigate back and >>>>> forth in your patch queues before finally posting them. >>>> I haven't used these yet. Is there a real benefit compared to using a >>>> normal git branch and rebase -i? Maybe I should try them if so. >>> I'm not only talking about rebasing, also about working within your >>> patch queue, editing patches in their middle, splitting it up, >>> reordering it etc. There are surely ways to do this with native git >>> (stgit is just a front-end and uses normal git), but that's not done >>> with two or three git commands. >> This is why I said rebase -i and not only rebase. In case you don't know >> this yet: It presents you a list of all commits you did since the point >> you're rebasing on. You can then drop, merge, edit (which includes >> splitting, see the man page of git-rebase) and change the order of them. > > It still lacks the flexibility and consistency of stgit-managed series > as it is designed around the original "rebase" step. With stgit, you are > permanently in "rebase -i" mode, you can go back and forth _while_ > editing. You can switch branches without leaving the rebase mode. You > can also hide patches temporarily (how do you do this with rebase -i?). Thanks, this is more or less what I wanted to know. (And I don't think I had to hide a patch yet, but I would either create another branch with the patch dropped or revert the patch and drop the revert commit later.) > However, in the end it is a question how you set up your personal > workflow. There are n ways to skin a cat. Sure. But as long as I only know m < n ways, there is always a chance to miss the better workflow. ;-) Kevin