A more proper solution is probably to teach "rerere" to remember
what modification (probably indexed via a patch ID for flexibility,
but either the pre- or post-image blob ID without such flexibility
is probably good enough) was deemed "uninteresting" to resolve in
favor of deletion and reapply it when we see another delete-modify
conflict with the same modification, but for now, treat all
delete-modify conflict to be with uninteresting modification.
The way the Reintegrate machinery is used makes it somewhat safer
than it looks---the initial attempt to merge (and come up with a
merge-fix if needed) will always be done using "git merge" and the
resulting commit is manually examined (if only to see if there is a
need for a further merge-fix) before redo-foo script is written out
of the resulting history. We'll need to deal with a case where a
modifying side need to be kept over the deleting side if/when it
arises, but so far I haven't seen such a case in real life.
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.
Junio C Hamano