Re: Make doc broken - 1d9a73b13ee576d28c0f41f5b243f2ebb1ff9fcf

[Graham Percival]

On Sat, Oct 22, 2011 at 04:41:35PM +0200, David Kastrup wrote:
> Dingdingding.  I don't think dev/staging should be _merged_, only
> fast-forwarded (do the merge using --ff-only).  If it is not
> forwardable, the dev/staging master should rebase it on master (so that
> it becomes fast-forwardable) and submit it to testing (if necessary, by
> overwriting dev/staging again).

Hmm.  At the moment, master and dev/staging cannot be "combined"
(to use hopefully non-specific terminology) with --ff-only.
Bertrand's 6ee8c04678442855cb794d4598c056c15c42673b gets in the
way of doing
  git merge --ff-only
in either way.

My initial instinct would be just to do
  git checkout master
  git merge dev/staging
..test...
  git push

but I'm going to hold off until you advise me on this.

> The problem is that a merge means
> a) the particular version to be committed has not been tested.

I don't think this is terribly important.  I mean, yes it's
theoretically true that 6ee8c04678442855cb794d4598c056c15c42673b
could have ruined your patches in dev/staging, but as long as the
combination can compile, we haven't *lost* any reliability
relative to the status quo.

> b) if one patch in the series is bad, the whole merge needs to be
>    reverted.  Reverting a merge is _really_ _really_ bad.  After that,
>    all changes are gone, but git is of the opinion that it has
>    considered all source patches already.  Cherry-picking any of them
>    won't help.  The only remedy is reverting the revert, and then
>    reverting single patches.  Ouch ouch ouch.

This sounds more serious.

Cheers,
- Graham