Re: reject "backwards" merges

From: David Kastrup <dak@gnu.org>
Date: Dec 13, 2014, 09:47 UTC
Message-ID: <877fxvdgpa.fsf@fencepost.gnu.org>
In-Reply-To: <CACh33FqHindeksHv7wcgu983oBSbm5G0ZswrQdTAz5tqgZdgjQ@mail.gmail.com>

Patrick Donnelly <batrick@batbytes.com> writes:

Show 8 quoted lines

> Is there a way to reject pushes that change the history of
> first-parents, caused by a "backwards" merge? To clarify by example
> (using branches instead of separate repositories):
>
> Here the desired first parent (HEAD^) would be commit
> 9cb303e2578af305d688abf62570ef31f3f113da. Unfortunately, the incorrect
> merge reversed the line of parents. Is there a way to prevent this
> from happening (via git-config) other than fixing the human?

You'd have to do this in a push hook. Before pushing, Git does not really have a way to figure out which kind of branch a merge will land on.

Most "reversed merges" probably come into being by having a fast-forward in a series of zig-zagged merges. Naturally the history before the fast-forward can only be "the right way round" for one of the two branches.

-- 
David Kastrup