As you may know, I made no less than three attempts to upstream my changes about preserve-merges last week.
This week began by a fourth one.
Johannes pointed out some problems with my commit messages on that series:
- some lines are too long
- they do not describe what I wanted to do well.
On the first point, commits messages should wrap at 72 characters, but I configured Emacs to wrap pretty much anything at 80 characters.
He also wanted to keep the original name of git_rebase__interactive__preserve_merges() (which I renamed git_rebase__preserve_merges()), but I decided not to, as this function is now part of git-rebase--preserve-merges.sh.
Also, Friday, Junio Hamano announced that my changes (among many others) have been merged into the pu (proposed updates) branch of git.git. This does not mean that it will necessarily hit master, but it’s a start.
When you start an interactive rebase, you’re greeted with your $EDITOR, containing a list of commits to edit, and an help text explaining you how this works.
The conversion itself is quite trivial, but strings are a rather curious case here: some of them begins with one or two newlines. As this becomes useless in C, Stefan advised me to remove them, as this would probably cause less confusion for the translators, but it implies changing the translations, as pointed out by Johannes and Phillip Wood. Right now, no clear opinion has emerged from the discussion.
Some additionnal work and refactoring could be made once more code has been converted. For instance, the todo-list file is opened, modified, and closed several times. Instead, we could create a strbuf, build it progressively, then write it once to the todo file.
I’ve started to work on converting the edit-todo functionnality of interactive rebase. This is also a straightforward change, but it would also require some future work once the conversion is completed.