The first pair are available as patches to git itself:

• git-splice – splices commits onto/into/out of current branch

  Jump to 08:44 in the video to see me introduce and demo this, or look at the slides, or read the man page for example usage.

• git-transplant – transplants commits from current branch onto/into another

  Jump to 32:22 in the video to see me introduce and demo this, or look at the slides, or read the man page for example usage.

The second pair are available as Python modules on PyPI, but both have a command-line interface too:

• git-deps – automatically detects textual dependencies between commits

  Jump to 41:28 in the video to see me introduce and demo this, or look at the slides, or read the README (which has a couple of short YouTube videos demoing the tool including the fancy web interface), or read my previous blog post about this.

• git-explode – explodes a linear sequence of git commits into new independent topic branches

  Jump to 51:10 in the video to see me introduce and demo this, or look at the slides, or read the README.

It’s taken a while to get them to a reasonable degree of polish, during which this work has been mostly under the radar, but now I’m now going to make a more concerted effort to advertise the tools, hence this blog post.

(Jump to 02:27 in the video to see me talk about this, or look at the slides.)

All developers face common problems:

• It’s difficult to predict what you’ll be doing next. One minute you might be working on a feature, the next you find a bug you need to fix, and the next you find some technical debt which requires refactoring.
• Multi-tasking is almost unavoidable.
• We’re human, so we sometimes screw up when trying to follow best practice workflow.

What does this mean when using git? Typically it means we are constantly juggling branches, and often need to manipulate the history of branches for various reasons, for example:

• Maintaining clean separation of topics between branches to facilitate code reviews: one branch for a refactoring, one for a bugfix, one for a feature, and so on.
• Backporting or forward-porting series of patches between branches.

My feeling is that while the git ecosystem has continued to evolve incrementally over the last few years, not much progress has been made in terms of automating this janitorial work, and that most people either do it by hand, or don’t bother doing it at all. This leads to unclean history, and/or more work and frustration for reviewers.

So I wrote these tools (and others) in an attempt to push the boundaries of automating git workflows to higher levels, as I explained on the git mailing list last year. Even if all the use cases they can cover have yet to be discovered, I hope you find them useful, or at least thought-provoking enough that you might join the effort!

I’d love some feedback, so do let me know what you think in the comments below.