For the GSoC 2018, I proposed to rewrite git-rebase--interactive, or interactive rebase for short. You may not know this specific feature of git, but it’s very useful. Basically, it allows you to reorganize commits in an interactive way. If you make a lot of commits like “quick fix”, followed by a “quick fix 2”, you should definitely check out this feature!
Rewriting interactive rebase
But why rewrite it? Well, currently, it’s written as a shell script. They have some advantages (they’re fast to write), but have a lot of drawbacks: they’re slow (especially on Windows), not really reliable, portability is hazardous… The goal would be to rewrite interactive rebase in C. It’s not perfect portability-wise, but it’s really better than shell scripts.
While I would like to rewrite everything during the three monthes of the GSoC, the goal is primarly to write good code that is actually mergeable, not to rush the project and to produce unusable code.
Currently, it’s the community bonding period. During this period, I’m exchanging with my mentors, Christian Couder and Stefan Beller, others members of the community (most notably, Johannes Schindelin, the creator of interactive rebase), and the two others GSoC students, Pratik Karki and Paul-Sebastian Ungureanu. They are also rewriting parts of git, respectively, git-rebase and git-stash. Check out their own posts, too!
Currently, there is some movements in git-rebase: the deprecation of --preserve-merges (or -p for short) in favour of the new --recreate-merges1, and a bit of refactoring, too.
Since -p uses interactive rebase internally, and we don’t really want to bother with it, I won’t rewrite it. Currently, -p is in the same file as interactive rebase. So, I will move -p in its own file, and then let it bitrot. For that, I will take advantage of Wink Saville’s patches, which refactored -p-specific code into their own functions.
So, this is the beginning of three exciting monthes, and of a weekly blog series about this journey.
|||Now called --rebase-merges|