Re: Make doc broken - 1d9a73b13ee576d28c0f41f5b243f2ebb1ff9fcf

[David Kastrup]

Graham Percival <address@hidden> writes:

> 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.

I'd do something like

git fetch
git rebase origin/master origin/dev/staging
[Note that you are now outside of any branch]
..test...
git push origin HEAD:master
git reset --hard master  or  git rebase origin master

And you are back to your own master...

>> 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.

It is a bloody nuisance.  I did that once in Lilypond development and
despaired getting my changes (even the unmodified whole merge commit)
back into the tree.  It did not help that kernel.org with its Howtos was
down.  Basically, don't revert a merge commit if you want to see any
commit of it ever again.  If you do, you have to revert the revert
itself, getting back to square 1 first before you can tackle the reason
for the revert in a way different from reverting the whole merge.  Or do
other tricks convincing git that the effect of the revert should not
prevail.

-- 
David Kastrup