LinuxCon + ContainerCon North America 2016

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, or any other development that includes rebasing.

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.

I've built a new tool, git-series, to track both a patch series and its evolution within the same git repository. git-series works entirely with existing git features, pushes and pulls to any git repository, and tracks a cover letter to accompany the series. I'll demonstrate the development workflow with git-series, and show the underlying architecture and git Data structures. I'll also present my experiences developing with Rust and libgit2.