ksummit.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Catalin Marinas <catalin.marinas@arm.com>
To: Josh Triplett <josh@joshtriplett.org>
Cc: "ksummit-discuss@lists.linuxfoundation.org"
	<ksummit-discuss@lists.linuxfoundation.org>
Subject: Re: [Ksummit-discuss] [ANNOUNCE] git-series: track changes to a patch series over time
Date: Fri, 5 Aug 2016 00:46:47 +0200	[thread overview]
Message-ID: <C3AB051F-EDE5-4CF3-9DFB-4AA96B974982@arm.com> (raw)
In-Reply-To: <20160729131151.GF4340@x>

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

-- 
Catalin

  reply	other threads:[~2016-08-04 22:46 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-29  7:50 Josh Triplett
2016-07-29 12:20 ` David Howells
2016-07-29 13:11   ` Josh Triplett
2016-08-04 22:46     ` Catalin Marinas [this message]
2016-08-04 23:07       ` Michael S. Tsirkin
2016-08-08 17:27         ` Catalin Marinas
2016-08-15 23:44           ` Michael S. Tsirkin
2016-08-04 23:46       ` Josh Triplett
2016-08-08 17:37         ` Catalin Marinas
2016-07-29 14:06   ` David Howells
2016-07-29 14:21     ` Christoph Lameter
2016-07-29 14:37       ` Josh Triplett
2016-07-29 15:00       ` Daniel Vetter
2016-07-29 15:18         ` Josh Triplett
2016-07-29 15:40           ` Daniel Vetter
2016-07-29 16:21             ` Josh Triplett
2016-07-29 16:31               ` Luis R. Rodriguez
2016-07-29 17:52       ` Bird, Timothy
2016-07-29 17:57         ` James Bottomley
2016-07-29 21:59           ` James Hogan
2016-07-30  2:55           ` Steven Rostedt
2016-07-29 20:13         ` David Howells
2016-07-30  5:02           ` Josh Triplett
2016-07-30  8:43             ` Arnd Bergmann
2016-08-04 12:44             ` Jani Nikula
2016-07-29 14:34     ` Josh Triplett
2016-07-29 14:37     ` David Howells
2016-07-29 14:56       ` Josh Triplett
2016-07-29 14:55 ` James Bottomley
2016-07-29 15:05   ` Josh Triplett
2016-08-09  0:10     ` Paul E. McKenney
2016-07-29 15:26 ` James Hogan
2016-08-04 23:52 ` Michael S. Tsirkin
2016-08-05 20:26   ` Josh Triplett
2016-08-15 13:20     ` James Hogan
2016-08-15 16:14       ` Josh Triplett
2016-08-15 23:42     ` Michael S. Tsirkin
2016-08-15 12:53 ` James Hogan
2016-08-15 16:34   ` Josh Triplett
2016-08-15 18:46     ` James Hogan
2016-08-15 21:35       ` Josh Triplett
2016-08-15 22:06         ` James Hogan
2016-08-15 23:59           ` Josh Triplett
2016-08-16  2:38             ` Michael S. Tsirkin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=C3AB051F-EDE5-4CF3-9DFB-4AA96B974982@arm.com \
    --to=catalin.marinas@arm.com \
    --cc=josh@joshtriplett.org \
    --cc=ksummit-discuss@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox