When the blurb pattern finds no match, the program only said that it
does not match and died. It would be very hard to make it report
that this and that token in the blurb text is misspelt and it would
match the pattern when that typo gets fixed, but at least it should
be able to dump the haystack it was looking for needles in to let
the human user do the guessing.
While waiting for build and test of the current round of
integration, we should be able to prepare the next round while on
a detached HEAD. By running
$ git co --detach master
$ INTO=jch Meta/redo-jch.sh
we can prepare a sequence of "Merge branch 'foo' into jch" commits
that can be used to replace 'jch' that is currently being tested,
without disrupting the test.
Before diving into inspecting each merge commit to see if it merges
more than two topics at the same time, we can count the number of
branches that are merged and the number of merge commits. If they
match, we can skip the more expensive check.
This will break if we merge a topic in multiple steps, but we do not
do that these days, so it would be a reasonable optimization.
When on branch T, detach the HEAD at the base of the branch, and
find the newest iteration of the same topic from lore, apply the
patches, and show the range-diff from what we have.
Depends on having healty "amlog" notes to allow us identify what
patch message resulted in the commit T, and working "b4 am" and the
lore archive that lets us grab the latest iteration.
If a topic B is built on top of a merge of topic A into master, then
we should merge topic A first before topic B when preparing the
integration branches. Merging topic B first would bring topic A
along with it, which is generally not a good idea if we consider A
and B as two separate topics.
Junio C Hamano