[Ksummit-discuss] [ANNOUNCE] git-series: track changes to a patch series over time

Michael S. Tsirkin mst at redhat.com
Mon Aug 15 23:44:06 UTC 2016


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 <josh at joshtriplett.org> wrote:
> > > > On Fri, Jul 29, 2016 at 01:20:12PM +0100, David Howells wrote:
> > > >> Josh Triplett <josh at joshtriplett.org> 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 <branch>.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


More information about the Ksummit-discuss mailing list