The maintainer’s Git time is spent on three activities.

The Policy

The policy on Integration is informally mentioned in "A Note from the maintainer" message, which is periodically posted to this mailing list after each feature release is made.

Note that before v1.9.0 release, the version numbers used to be structured slightly differently. vX.Y.Z were feature releases while vX.Y.Z.W were maintenance releases for vX.Y.Z.

A Typical Git Day

A typical Git day for the maintainer implements the above policy by doing the following:


Some observations to be made.


Preparing a "merge-fix"

A merge of two topics may not textually conflict but still have conflict at the semantic level. A classic example is for one topic to rename an variable and all its uses, while another topic adds a new use of the variable under its old name. When these two topics are merged together, the reference to the variable newly added by the latter topic will still use the old name in the result.

The Meta/Reintegrate script that is used by redo-jch and redo-pu scripts implements a crude but usable way to work this issue around. When the script merges branch $X, it checks if "refs/merge-fix/$X" exists, and if so, the effect of it is squashed into the result of the mechanical merge. In other words,

$ echo $X | Meta/Reintegrate

is roughly equivalent to this sequence:

$ git merge --rerere-autoupdate $X
$ git commit
$ git cherry-pick -n refs/merge-fix/$X
$ git commit --amend

The goal of this "prepare a merge-fix" step is to come up with a commit that can be squashed into a result of mechanical merge to correct semantic conflicts.

After finding that the result of merging branch "ai/topic" to an integration branch had such a semantic conflict, say pu~4, check the problematic merge out on a detached HEAD, edit the working tree to fix the semantic conflict, and make a separate commit to record the fix-up:

$ git checkout pu~4
$ git show -s --pretty=%s ;# double check
Merge branch 'ai/topic' to pu
$ edit
$ git commit -m 'merge-fix/ai/topic' -a

Then make a reference "refs/merge-fix/ai/topic" to point at this result:

$ git update-ref refs/merge-fix/ai/topic HEAD

Then double check the result by asking Meta/Reintegrate to redo the merge:

$ git checkout pu~5 ;# the parent of the problem merge
$ echo ai/topic | Meta/Reintegrate
$ git diff pu~4

This time, because you prepared refs/merge-fix/ai/topic, the resulting merge should have been tweaked to include the fix for the semantic conflict.

Note that this assumes that the order in which conflicting branches are merged does not change. If the reason why merging ai/topic branch needs this merge-fix is because another branch merged earlier to the integration branch changed the underlying assumption ai/topic branch made (e.g. ai/topic branch added a site to refer to a variable, while the other branch renamed that variable and adjusted existing use sites), and if you changed redo-jch (or redo-pu) script to merge ai/topic branch before the other branch, then the above merge-fix should not be applied while merging ai/topic, but should instead be applied while merging the other branch. You would need to move the fix to apply to the other branch, perhaps like this:

$ mf=refs/merge-fix
$ git update-ref $mf/$the_other_branch $mf/ai/topic
$ git update-ref -d $mf/ai/topic