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 0BF66958 for ; Fri, 29 Jul 2016 15:18:25 +0000 (UTC) Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [217.70.183.194]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5741C28C for ; Fri, 29 Jul 2016 15:18:24 +0000 (UTC) Date: Fri, 29 Jul 2016 08:18:17 -0700 From: Josh Triplett To: Daniel Vetter Message-ID: <20160729151817.GD12137@x> References: <20160729131151.GF4340@x> <20160729075039.GA26402@x> <30809.1469794812@warthog.procyon.org.uk> <1596.1469801212@warthog.procyon.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: Christoph Lameter , "ksummit-discuss@lists.linuxfoundation.org" Subject: Re: [Ksummit-discuss] [ANNOUNCE] git-series: track changes to a patch series over time List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Fri, Jul 29, 2016 at 05:00:06PM +0200, Daniel Vetter wrote: > On Fri, Jul 29, 2016 at 4:21 PM, Christoph Lameter wrote: > > On Fri, 29 Jul 2016, David Howells wrote: > > > >> Josh Triplett wrote: > >> > >> > Note that git-series doesn't provide a quilt-style push/pop workflow, > >> > with applied and unapplied patches; it just looks at HEAD. > >> > >> Ah... In that case it's probably not a sufficient substitute for how I use > >> stgit. > > > > Did not know that there was stgit. Still stuck on quilt since > > I like editing the files directly (its often easier to edit the diffs if > > you want to rename things etc). > > > > Interesting projects. > > Shameless plug of our own tooling for maintainer a quilt pile and > tracking it in git: > > https://cgit.freedesktop.org/drm-intel/tree/qf?h=maintainer-tools > > It even tracks the baseline sha1 and pulls/pushes it in hidden remote > refs/. Which all together allows you to git bisect on the quilt > branch, which is a really powerful thing for a long-lived rebasing > patch pile. quilt+git was the only thing that allowed me to glue > something git bisect capable together. By "bisect on the quilt branch", do you mean bisecting between versions of the overall patch series? That does seem quite helpful, if you need to figure out at what point a change occurred in the patch series to break something. I've filed https://github.com/git-series/git-series/issues/3 about supporting that. > And the other reason is the same you have: Editing raw patches is > really powerful for doing rebases over mechanical changes. Function > renames become a trivial quilt pop -a ; sed; while quilt push ; do > make ; done. Interesting! I'll have to give that some thought, to figure out if I can support workflows like that. What other kinds of changes do you tend to make by editing patches directly? I'm tempted to add a "git series filter" that applies filter-branch to the commits in the series, or something similar to that. I'll also have to think about the use case of testing each commit in the series, to see if that needs support from git-series or just from underlying git tools. - Josh Triplett