There are cases where a reintegrate merge into a sparse working copy causes
problems in subsequent merges.
Kevin Cathcart reported one such problem here:
I've found what really looks to be a buggy edge case with
the automatic merge feature of 1.8.X which can occur if:
* a partial (reintegrate-like) merge into a sparse working
copy is committed
* and then immediately followed by merging the same branch again
into a full working copy.
By a partial merge I specifically mean that the sparse working
copy was missing a target of the merge.
Here is a diagram of the branching in question:
/ / & \
(Obviously the ampersand indicates the partial merge due
to sparse WC. Also two commits are showing a name along
with a revision number).
With that particular pattern I see two anomalies
that do not occur if the order of commits X and Y are
/ / & \
The important part here is "that [problems] do not occur if the order of commits
X and Y are reversed". This seems odd, and should be investigated.