Git Rev News: Edition 37 (March 21st, 2018)

Welcome to the 37th edition of Git Rev News, a digest of all things Git. For our goals, the archives, the way we work, and how to contribute or to subscribe, see the Git Rev News page on

This edition covers what happened from the month of February 2018 up to the Git Merge conference on March 7th and 8th 2018.



Another exciting Git Merge happened this year, this time in the lovely city of Barcelona in Catalonia, Spain. Surrounded by crazy skaters, two days full of Git happened, with a couple of add-on events on both ends.


Hilco Wijbenga explained to the mailing list that sometimes when a rebase fails because of rebase/merge conflicts, he would like to “rewind” the rebase to an earlier commit and restart from there. This would be useful for example when the earlier commit is the right commit where a conflict should be fixed.

His current solution is to abort the rebase and start over with git rebase --interactive and then “edit” commits. This doesn’t work well though when a lot of conflicts have already been resolved before the earlier commit he would “rewind” to, because, when the original rebase is aborted, all the work that already went into resolving conflicts is lost.

Brian Carlson replied to Hilco that in this case he unstages all the changes from the index, then makes the change that should have gone into the earlier commit, uses git commit --fixup (or --squash), and then restages the rest of the changes and continues with the rebase. He can then use git rebase -i --autosquash afterwards to insert the fixup commit into the right place.

Hilco replied to Brian that he ends up doing that too, but it doesn’t work well when the fixup commit is not easy to move to the right place.

Jeff King, alias Peff, replied to Hilco’s original email saying that git rerere should help reapplying conflict resolutions. He also suggested to “simply pick the resolved state at each step” when repeating the rebase, using for example git tag failed to remember the failed attempt, and then git checkout failed~4 -- to pick conflict resolutions from the failed attempt.

Peff alternatively suggested “rewinding” using git reset --hard and then, after fixing the earlier commit, using git cherry-pick to cherry-pick commits with conflict resolutions from the failed attempt.

Johannes Schindelin, alias Dscho, also replied to Hilco. Dscho first suggested basically the same workflow as Peff’s alternative suggestion.

He then suggested an alternative strategy which consists in copying parts of the $GIT_DIR/rebase-merge/done file to the beginning of the $GIT_DIR/rebase-merge/git-rebase-todo file, instead of cherry-picking commits. This copying would in effect “rewind” the original rebase.

Dscho mentioned that a new interactive rebase subcommand could be created to facilitate using this strategy. The new subcommand could “make use of the fact that the interactive rebase accumulates mappings between the original commits and the rewritten ones” in the $GIT_DIR/rebase-merge/rewritten-list file.

Phillip Wood also replied to Hilco’s first email suggesting something similar as Dscho’s alternative strategy. Phillip suggested using git log --pretty="pick %h %s" <earlier_commit>.. followed by git rebase --edit-todo to edit the git-rebase-todo file, and then git checkout <earlier_commit> to rewind.

In a subsequent email replying to himself Dscho elaborated on a possible new subcommand. He proposed git rebase --replay-latest-commits 3 and a sightly different way to copy commits to the git-rebase-todo file so that it contains commits with resolved merge conflicts.

Phillip replied to Dscho that it’s the reason why he actually uses git log --pretty="pick %h %s" <earlier_commit>.. to get the lines that should be pasted at the beginning of the git-rebase-todo file.

Peff replied to Dscho suggesting a “general form” of Dscho’s proposal that would be called git rebase --rewind and that could “undo” the prior rebase command whatever it is.

Jacob Keller, alias Jake, chimed in to support Peff’s suggestion and Hilco’s wish of “a --rewind that simply tracks the point of each history and can reset back to each”.


Other News


Light reading

Git tools and sites


This edition of Git Rev News was curated by Christian Couder <>, Jakub Narębski <>, Markus Jansen <> and Gabriel Alcaras <> with help from Johannes Schindelin and Patrick Steinhardt.