Preparing for the next cycle

While hunting for last-minute embarrasing bugs before the final release of upcoming Git version 1.7.9, those in the Git development community have been busy preparing their own topics to scratch various itches of their own. As we have been in the pre-release feature freeze for about three weeks by now, there have been quite a few such topics, waiting to become part of the release after 1.7.9, being tested in the 'next' branch. I counted 48 patches spanning 23 topics.

Kind	Topics	Patches
Fixes	9	19
UI, Workflows & Features	7	10
Performance	2	6
Internal Implementation	5	13

I've been re-reading them to check their sanity for the past several days, and they all look more or less ready to go. I expect that the next cycle after version 1.7.9 is released will be a short one, just like this cycle leading to 1.7.9 has been.

One of the potentially contentious topic is a change to the git merge command. In the versions up to the upcoming 1.7.9, when the changes from histories being consolidated merge cleanly without conflict, the command records the result without any extra user interaction, using a commit log message that is auto-generated based on the name and contents of the branch being merged.

Linus recently admitted that this is one of the regrettable UI mistakes we made in the early days of Git. This behaviour led too many people to blindly make merge commits that merge into their topic branches, whose purpose is to develop a feature and fix in isolation, of the upstream branch, whose purpose is to integrate assorted topics and move the overall project forward, without justifying why such a merge in a wrong direction was necessary to advance their topics. Of course, git commit --amend command can be used to update the merge commit log message after git merge is done, and the recent git merge command can be given the --edit option to open an editor, but in practice, not many people bother to perform such an extra step only to strive for long term health of the project history.

Just like the git commit command encourages users to explain and justify their non-merge commits by opening an editor and have them describe the commit, the git merge command in the version of Git after the upcoming version 1.7.9,  when used interactively, will open an editor, so that the user can further edit the auto-generated merge commit log message and explain why the merge was made.

Oh, I've also been working on a topic that will get ready far in the future, but that will be another article.