[GSoC] GSoC with git, week 5

[Alban Gruin <alban.gruin@gmail.com>]

Hi,

I wrote a post about this week. Unfortunately, I have a technical issue
with my website, so you can find it right in this email instead. I’m
sorry about that. I will publish it on my blog as soon as it comes back
online.

Feel free to give me your feedback!

Cheers,
Alban


--

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[1].

4th attempt
-----------

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[2] 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.

TODO: help
----------

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.

So, this week, I rewrote the code writing this message from shell
to C. You can find the branch here[3], and the discussion on the list
here[4].

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.

What’s next?
------------

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.

[1]
https://public-inbox.org/git/20180528123422.6718-1-alban.gruin@gmail.com/
[2] https://public-inbox.org/git/xmqqa7sf7yzs.fsf@gitster-ct.c.googlers.com/
[3] https://github.com/agrn/git/tree/ag/append-todo-help-c
[4]
https://public-inbox.org/git/20180531110130.18839-1-alban.gruin@gmail.com/