

The end result is an interactive rebase that, according to a benchmark included in Git’s source code, runs ~5x faster on Windows, ~4x faster on MacOSX and still ~3x faster on Linux. As rebase -i had turned into a monster of a shell script in the meantime, my idea was to go for an incremental route: re-implement some parts of the interactive rebase in C and switch the shell script over to use those parts, one by one. Also, Git for Windows has to resort to a POSIX emulation layer to run shell scripts, which means an enormous performance impact.īeing a power user of the interactive rebase myself, I hence set out to address this problem. This matters especially on Windows, where it is more expensive to spawn processes than, say, on Linux. The initial version was a very simple shell script, and here lies the rub: shell scripting is good for prototyping quick and dirty, but it lacks direct access to Git’s data structures, proper error handling, and most importantly: speed.
#Windows version of gitx code
Essentially, it generates a list of commits called “edit script” or “todo script”, lets the user edit that script, and then re-applies the code changes accordingly. Originally intended as a simple side project to help myself contribute changes to the Git project itself, it evolved into a very powerful tool that helps with refining topic branches until they are ready to be merged. It is called the interactive rebase, or rebase -i. One of Git’s most powerful commands lets the user reorder commits, edit commit messages and split/join commits. Let me take this opportunity to mention a couple of highlights: The interactive rebase is now much faster Most importantly, Git for Windows v2.10.0 has been released.

It has been a busy time since my last post. There have been nine public releases of Git for Windows in the meantime.
