Announce: git-series


#1

I’d like to announce a project I’ve been working on for a while:

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.

I found Rust and the git2-rs bindings for libgit2 incredibly helpful when writing git-series. Thanks to all the Rust developers, and especially to @alexcrichton, @ogham, and @kbknapp.


#2

Nice! I’ve only taken a preliminary look at the readme/docs so far, but this seems like a perfect match for a feature I’ve wanted in Git for a long time. It’s so silly that standard Git workflows force you to choose between merging dirty WIP history to master, making it difficult to identify which commits correspond to a given feature/bugfix and all but impossible to organize a pull request into a series of multiple patches… or using rebase, which solves that at the cost of regularly throwing away history and blocking collaboration.

(Now that we have two axes of history, all we need to do is find one more and we’ll have a time cube!)


#3

Thanks! That was exactly my goal when writing it; I wanted to work with projects that wanted clean rebased histories when merging, while maintaining the “real” development history. Please let me know if it works for you, or if you need anything else from it.