Git branch aware rebase helper

[NonLogicalDev]

Hey Joshua, for some reason I was thinking I saw a script that you may or may not have written to help with a situation where you might be working on multiple feature branches and have for example a layout like so:

Suppose you are on branch feature-4:

master [bc1]
    feature-1 [c1]
       feature-2 [c2]
           feature-5 [c5]
       feature-3 [c3]
           feature-4 [c4] (*)

Your git log will then looks like this:

00004: (feature-4) c4
00003: (feature-3) c3
00002: (feature-1) c1
00001: (master) bc1

And want to rebase against latests master while preserving all of branch names. Have I seen that here or somewhere else? =]

[jcorbin]

Hey there, you might be thinking of https://github.com/abhinav/restack that @abhinav made to assist with that, my solution is a bit more lightweight, and isn't a standalone tool:

• a couple of vimrc normal mode mappings to assist with inserting branch updates and editing around them
• they anchor (imperfectly!) on the branch decorations left by my gitconfig

So for me, the experience is all in-editor and usually looks like:

• NOTE: my leader is \ but you can ready that as , or whatever you have mapleader set to; ignore this entirely if not a vim user ;-)
• \bf insertsbranch -f lines after every recognizable pick line with a branch decoration
• I usually then delete the last one, as it's a spurious "update the branch being rebased", which git-rebase otherwise breaks wrt ; usually this is something like dG on the last match, so maybe GN to get to the last match?
• commonly I'll insert some blank lines after the branch updates with something like \gbfO<cr> ; my \gbf mapping primes you to do a gren transformation anchored every exec branch -f ... line ; if you're used to an editor with multiple cursors, think of it that way: it edits every exec branch -f ... line ( in normal mode )

This is an in-exact / imprecise process, but I prefer such a whitebox mode to the blackbox of a maximally convenient tool, as it tends to: 1) engage me more in actually editing / considering / reviewing my rebase plan and 2) adapts well to more complicated scenarios, say if you want to update other side-branches ( not just one stack ) or other non-linear scenarios.

[NonLogicalDev]

Hey @jcorbin thank you for your reply! Over the last year I have evaluated a bunch of options and together with @abhinav we have concluded that https://github.com/stacked-git/stgit is the most versatile approach.

It allows more interactive stack management, which is a bit easier to work with than Git rebase TODO file. And it allows you to switch branches or push/pop patches to work on other things mid stack, which opens up a world of interesting possibilities.