Which of the following is not a variant of merge sort?

A change to merge sort counts as a real "variant" only when it still performs the same divide-and-merge principle — splitting a sequence and combining sorted pieces — while altering something like traversal order (recursive vs iterative) or auxiliary space use. It can never escape the comparison-sort lower bound: any algorithm that sorts by comparing elements needs at least on the order of n·log2(n) comparisons in the worst case, so no comparison-based sort can run in O(n) (linear) time.

Checking each option against that principle:

• Top-down merge sort: the classic recursive version — split the array into two roughly equal halves until single elements remain, then merge pairs back together in order.

• Bottom-up merge sort: an iterative version — start by treating every element as a sorted run of size 1, then repeatedly merge adjacent runs (size 1→2, 2→4, …) until one sorted array remains.

• In-place merge sort: modifies the merge step itself (e.g. block rotation/swapping) so it needs no separate O(n) auxiliary array — harder to implement, but a real, studied variant.

• "Linear merge sort": would require O(n) overall time, which no comparison-based sort — including merge sort — can achieve.

To distinguish n elements by pairwise comparison, at least log2(n!) ≈ n·log2(n) comparisons are needed in the worst case — this is exactly the bound merge sort already meets with its Θ(n log n) running time. No restructuring of merge sort can push it below that bound, so a true O(n) "linear merge sort" cannot exist; only the other three are genuine variants. (Note: this is separate from the fact that the standard merge sort implementation itself is not in-place — that is precisely why in-place merge sort exists as its own distinct, real variant.)

The option that is not a real variant of merge sort is "linear merge sort".