Re: bad merge in staging

[David Kastrup]

Graham Percival <address@hidden> writes:

> We've got a mess in master now, starting with
> 0f68a5a1b6f789c2a0ec0e4584a3495832a3b6d7
>
> I noticed the problem before Patchy ran, but I assumed that the
> merge --ff-only  would reject the mess.  Unfortunately it didn't,
> so we now have a span of a few commits that will fail to compile,
> as well as some duplicated commits.
>
> Mike, what did you do when you pushed your addition of
>   5657e399609abfa2436aeec74e2498d16219e813
> ?  I want to find out if there were any warnings that you skipped
> over, or if Patchy needs some extra checks, or what.  The whole
> point of Patchy is that we should avoid this situation.
>
> I have vague suspicions about git pull -r vs. git pull; we used to
> be told to always use git pull -r but it appears that David favors
> plain git pull (or rather: a combination of git fetch and
> something else).

If Mike had used git pull -r instead of a plain pull without rebase,
this "mess" would not have happened.

For small-scale changes, git pull -r is pretty much the right idea
before pushing to staging.  For synchronizing large branches (like
staging with master) it is quite a bad idea.

> If that's the cause of this problem, let's get the CG cleared up.

In general, you want to rebase to staging before pushing to staging.
Always.

Since pulling tends to do things I don't want (too much cleverness
involved), I usually avoid it.

In any case, if a pull tells you that it _merged_ something, don't
further proceed blindly.  Check what you are doing.

The "mess" that Mike left is typical for large scale branches, and it
could be fast-forwarded from staging to master (including the mess's
structure) once Mike put it to staging, so Patchy had no reason trying
to reorganize the material.

Patchy does _not_, _never ever_ reorganize anything when moving it from
staging to master.

So committers should check the version of staging they are going to push
_before_ pushing it.

-- 
David Kastrup