It is kind of surprising but this week I named a topic name with '+'
in it for the first time, and for that branch the pattern did not
match and failed to annotate it with the description.
The reintegrate script can have "### cut here" comments to separate
the list of topics at certain points to group them better. Add a
blank line after them to make a long list easier to see.
A typical entry in whats-cooking.txt begins with the description of
the topic, followed by "Will do what to this topic" declaration of
the decision (i.e. $willdo verb) and supplemental text to explain
the decision. When we read such an entry to add to a merge log
message, we omit the line with "Will do what".
Instead, stop reading there to exclude the supplemental text from
the merge log.
When down-merging old topics that graduated to 'master' some time
ago to maintenance tracks, Meta/whats-cooking.txt that is checked
out would no longer have the release notes entry for the topics.
Look for recent editions of what's cooking report in such a case.
While rebuilding an integration branch, some topics may need custom
merge options, such as -Xsubtree=where/, to explicitly tell where
that foreign history sits in our tree. Teach the Reintegrate script
to pay attention to branch.$name.rebuild configuration, e.g.
[branch "jl/git-gui-show-added-submodule-changes"]
rebuild = -Xsubtree=git-gui/
to allow customization.
Using empty commits on the throw-away trial integration branches,
keep track of the "doneness" comments in the history, so that
later run of "redo-*.sh -[ud]" can resurrect them.
This _might_ make things easier to read, together with an extra
blank line between each topic.
Adjust Meta/Reintegrate to read and strip the extra indentation to
avoid breaking the merge log messages. "Meta/cook -w" also has
been adjusted to read and strip the extra indentation before finding
the markers for "will-do".
As "git merge" is clever not to default to --edit behaviour when its
standard input and output streams are not connected to the same
terminal (i.e. indicating an interactive tty session), we would need
to explicitly ask for "--edit" while exporting "EDITOR=:" one-shot,
so that commit log cleaner still is triggered.
In the longer term, the interactions among pull, fmt-merge-msg,
merge and the editor need to be redesigned, but it is a large task,
so for now this workaround should suffice.
For --no-edit to be true replacement of one-shot export of EDITOR=:,
it should trigger stripspace() to remove comments, but currently it
doesn't. Avoid using it for now.
This will let me run 'Meta/Reintegrate -e' and feed the selected branches
while on 'master', i.e. the final graduation ceremony, and clean up the
merge messages.
This is especially necessary when you reverted a premature merge
to more stable integration branch while you do want to keep the
topic cooking in more experimental integration branch.
