Patrick Donnelly <batr...@batbytes.com> writes: > 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
