From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LylGd-0004V6-03 for qemu-devel@nongnu.org; Tue, 28 Apr 2009 07:14:27 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LylGY-0004SJ-3I for qemu-devel@nongnu.org; Tue, 28 Apr 2009 07:14:26 -0400 Received: from [199.232.76.173] (port=49813 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LylGX-0004SC-Of for qemu-devel@nongnu.org; Tue, 28 Apr 2009 07:14:21 -0400 Received: from gecko.sbs.de ([194.138.37.40]:15273) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LylGX-000300-BD for qemu-devel@nongnu.org; Tue, 28 Apr 2009 07:14:21 -0400 Message-ID: <49F6E506.5030506@siemens.com> Date: Tue, 28 Apr 2009 13:14:14 +0200 From: Jan Kiszka 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> <49F6E151.8030507@redhat.com> In-Reply-To: <49F6E151.8030507@redhat.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: Kevin Wolf Cc: Laurent Desnogues , Christoph Egger , "C.W. Betts" , qemu-devel@nongnu.org Kevin Wolf wrote: > 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. ;-) > Yeah, true. For that and some other reasons it would be great if git itself could gain fully flexible queue management. stgit is only a workaround that has some downsides, too (same for guilt). Once I'll find its core features natively, I'm going to switch over to have only a single UI. Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux