Bisection/merge commits (was: PATCH: Countdown to 20111027)

[David Kastrup]

Graham Percival <address@hidden> writes:

> On Wed, Oct 26, 2011 at 03:55:13PM +0200, David Kastrup wrote:
>> Graham Percival <address@hidden> writes:
>> 
>> > that is a concern, but I have no energy left to be concerned about it.
>> > Note that merging from dev/staging to master will be completely
>> > automatic (including the tests to determine if this is safe).
>> 
>> It can't always be automatic if parallel pushes to master happened and
>> staging needs to get rebased first (else pushing will not be
>> permissible, and testing is point of moot).  Some rebases don't go
>> through without manual intervention.
>
> If that happens, then we have a wailing and gnashing of teeth and
> somebody does it manually.  So rewrite that previous sentence as
> "as long as the tests determine that merging is safe, the merging
> is completely automatic; if anything goes wrong, there is a
> wailing and gnashing of teeth and somebody needs to shovel the
> garbage by hand".

Can you figure out what steps you did for pushing staging to master,
perhaps using the reflog or other personal history?  I made sure that I
had a merge commit in staging for doing the tuning work.

In master, it has been added as _two_ commits.  That's bad news for
bisection since after the first commit, stuff does not compile anymore.
I don't think we can easily fix this without causing more pain than we
already did (by rewriting this, pulling will result in a merge for
everyone who already did pull, and rebasing will likely stop in between
once afterwards).

Ugly, ugly.  We should make sure that this does not happen again.  If
merge commits are too easy to get wrong when moving staging to master,
we have to forego them completely.

-- 
David Kastrup