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.
In a workflow that uses topic branches heavily, you would need to keep
updating test integration branch(es) all the time. If they are managed
like my 'next' by merging the tips of topics that have grown since the
last integration, it is not so difficult. You only need to review output
from "git branch --no-merged next" to see if there are topics that can and
needs to be merged to 'next'.
But sometimes it is easier to rebuild a test integration branch from
scratch all the time, especially if you do not publish it for others to
build on.
I've been using this script for some time to rebuild jch and pu branches
in my workflow. jch's tip is supposed to always match 'next', but it is
rebuilt from scratch on top of 'master' by merging the same topics that
are in 'next'. You can use the same script in your work.
To use it, you give a commit range base..tip to the script, and you will
see a shell script that uses a series of 'git-merge'. "base" is the more
stable branch that you rebuild your test integration branch on top (in my
case, 'master'), and "tip" is where the tip of the test integration branch
is from the last round (in my case, 'jch' or 'pu').
Then you can run the resulting script, fix conflicted merge and use
'git-commit', and then repeat until all the branches are re-integrated on
top of the base branch.
$ Meta/Reintegrate master..jch >/var/tmp/redo-jch.sh
$ cat /var/tmp/redo-jch.sh
#!/bin/sh
while read branch eh
do
case "$eh" in
"") git merge "$branch" || break ;;
?*) echo >&2 "Eh? $branch $eh"; break ;;
esac
done <<EOF
jc/blame
js/notes
ks/maint-mailinfo-folded~3
tr/previous-branch
EOF
$ git checkout jch
$ git reset --hard master
$ /var/tmp/redo-jch.sh
... if there is conflict, resolve, "git commit" here ...
$ /var/tmp/redo-jch.sh
... repeat until everything is applied.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
