Hi Josh,

On Fri, Jul 29, 2016 at 12:50:39AM -0700, 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.
> 
> git-series provides a tool for managing patch series with git, tracking
> the "history of history". git series tracks changes to the patch series
> over time, including rebases and other non-fast-forwarding changes. git
> series also tracks a cover letter for the patch series, formats the
> series for email, and prepares pull requests.
> 
> This makes it easier to collaborate on a patch series, distribution
> package, backport, or any other development process that includes
> rebasing or non-fast-forward development.
> 
> A patch series typically goes through multiple iterations before
> submission; the path from idea to RFC to [PATCHv12 1/8] includes many
> invocations of git rebase -i. However, while Git tracks and organizes
> commits quite well, it doesn't actually track changes to a patch series
> at all, outside of the ephemeral reflog. This makes it a challenge to
> collaborate on a patch series, distribution package, backport, or any
> other development process that includes rebasing or non-fast-forward
> development.
> 
> Typically, tracking the evolution of a patch series over time involves
> moving part of the version control outside of git. You can move the
> patch series from git into quilt or a distribution package, and then
> version the patch files with git, losing the power of git's tools. Or,
> you can keep the patch series in git, and version it via multiple named
> branches; however, names like feature-v2, feature-v3-typofix, and
> feature-v8-rebased-4.6-alice-fix sound like filenames from corporate
> email, not modern version control. And either way, git doesn't track
> your cover letter at all.
> 
> git-series tracks both a patch series and its evolution within the same
> git repository. git-series works entirely with existing git features,
> allowing git to push and pull a series to any git repository along with
> other branches and tags. Each time you change the patch series, whether
> fast-forwarding or not, you can "git series commit" a new version of the
> patch series, complete with commit message.
> 
> You can rebase a patch series with "git series rebase -i", format it for
> submission with "git series format", or send a "please pull" request with
> "git series req".  git-series knows the base of your series, so you
> don't need to count patches or find a commit hash to run rebase or
> format.
> 
> If you're interested in trying git-series, see
> https://github.com/git-series/git-series for installation instructions
> and a "getting started" guide.
> 
> I've also documented the internal storage format of git-series at
> https://github.com/git-series/git-series/blob/master/INTERNALS.md ,
> including the details for how git-series ensures git can always reach,
> push, and pull a series.
> 
> I'd welcome any feedback, whether on the interface and workflow, the
> internals and collaboration, ideas on presenting diffs of patch series,
> or anything else.

Thats pretty neat, thanks! I do loads of rebasing when preparing
patchsets, and tend to just rely on reflog if something goes wrong and I
need to look back at the history.

It looks like it could work quite well for tracking linux-next style
trees (not necessarily linux-next itself) that automatically regenerate
a bunch of merges of different branches each time one of them changes
(if you ignore git series format & git series rebase, since they
wouldn't be relevant and don't like merge commits anyway).

It may be helpful to be able to easily tag versions of the series, e.g.
rfc/v1/v2 etc when you actually submit them (sure, the git-series ref
could be tagged manually according to some naming convention, or perhaps
storing it in the metadata would make it more self-contained).

I use various git aliases / scripts for diffing patchsets, mainly based
around vimdiff'ing git log A...B --{left,right}-only | grep to filter
out irrelevant lines of diff (like index lines), but that all sort of
breaks down as soon as you reorder commits, requiring me to e.g.
manually edit one side and :diffupdate to be able to check the changes.

Cheers
James