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 D14FA26C for ; Mon, 15 Aug 2016 23:44:10 +0000 (UTC) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5B78A165 for ; Mon, 15 Aug 2016 23:44:10 +0000 (UTC) Date: Tue, 16 Aug 2016 02:44:06 +0300 From: "Michael S. Tsirkin" To: Catalin Marinas Message-ID: <20160816024253-mutt-send-email-mst@kernel.org> References: <20160729075039.GA26402@x> <30809.1469794812@warthog.procyon.org.uk> <20160729131151.GF4340@x> <20160805020118-mutt-send-email-mst@kernel.org> <20160808172711.GA8436@e104818-lin.cambridge.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160808172711.GA8436@e104818-lin.cambridge.arm.com> Cc: "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 Mon, Aug 08, 2016 at 06:27:11PM +0100, Catalin Marinas wrote: > On Fri, Aug 05, 2016 at 02:07:15AM +0300, Michael S. Tsirkin wrote: > > On Fri, Aug 05, 2016 at 12:46:47AM +0200, Catalin Marinas wrote: > > > On 29 Jul 2016, at 15:12, Josh Triplett wrote: > > > > On Fri, Jul 29, 2016 at 01:20:12PM +0100, David Howells wrote: > > > >> Josh Triplett wrote: > > > >>> I'd like to announce a project I've been working on for a while. I sent > > > >>> this announcement to LKML, but since many people don't subscribe to LKML > > > >>> directly, and since ksummit-discuss has had several discussions > > > >>> specifically about patch workflow and development processes, I thought > > > >>> I'd send the announcement here as well, in case anyone found it useful > > > >>> for their workflow. > > > >> > > > >> Can this be used as a direct substitute for stgit for maintaining a patch > > > >> series? > > > > > > > > Yes, that's exactly what I designed it for. git-series has the added > > > > advantage of tracking the versions of the patch series across rewrites. > > > > stgit just directly rewrites history, like rebase -i does; as far as I > > > > know, it doesn't remember the old history. You'd have to go to the > > > > reflog for that. > > > > > > I haven't looked at git-series yet (I actually have a git "series" alias > > > to list the current commits against a parent/tracking branch) > > > but StGit does remember the series history. It stores all the past states > > > of a series in a .stgit branch and you can inspect the > > > changes, get unlimited undo/redo, even show a diff of diffs for > > > a given patch. > > > > > > > Note that git-series doesn't provide a quilt-style push/pop workflow, > > > > with applied and unapplied patches; it just looks at HEAD. > > > > > > Even though I'm the original author of StGit, I find myself using it less > > > and less these days as I'm busier integrating others' patches than > > > creating my own series from scratch. But what I miss though in plain git is the patch "pop" functionality. At > > > some point I may add a 'git stash head' feature to git which > > > would stash away the HEAD commit without losing its content (and > > > the corresponding 'git stash apply' restoring the original commit). > > > > This will stash an arbitrary commit: > > #!/bin/sh > > > > commit="${1}"; > > git tag -f stash ${commit} > > git rebase --onto ${commit}~1 ${commit} > > > > and > > > > git cherry-pick stash > > > > will unstash > > Thanks for the tip. All it needs is some refining to be able to stash > multiple commits (linking into a branch similar to the 'stash' would do; > I had a plan to do something similar for stgit but we ended up with a > more metadata). Yes - generally a new kind of object that is more like a tag than a commit but can point at a list of commits and not just a single one would solve many problems like this. > -- > Catalin