Re: bad merge in staging

[David Kastrup]

David Kastrup <address@hidden> writes:

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

I could teach Patchy to not proceed whenever the moved material would
include a merge commit, or a merge commit with standard merge message
(meaning that you would have to do an explicit merge with a manually
written merge message if you really wanted to have a merge commit move).

That's all rather hand-wavy and fragile.

The #1 sanity rule, of course is:

CHECK WHAT YOU ARE PUSHING!!!!!

git log --graph --decorate staging

or so should give you a good idea what you are doing.  And you do that
_right_ before you push, _without_ any intervening pulls or anything
else.

Patchy does not check the internal structure of staging.  It just checks
that it is a straight descendent of master.

git is pretty good with dealing with criss-cross merges (as long as
nobody bypassed its knowledge of things, like by working with non-git
patches from Rietveld), so it is likely even possible to revert one of
the "duplicate" commits and get the correct result.

But it makes the history quite harder to read and work with.  So again:

CHECK WHAT YOU ARE PUSHING!!!!!

-- 
David Kastrup