I have attached two repositories, where htam-4.16 is a cherry picked 
version of "htam". When I push or pull patches between htam and htam-4.16 
I get:

This is a bug! Please report it at http://bugs.darcs.net or via email to 
bugs@darcs.net:
failed to commute common patches
CallStack (from HasCallStack):
   error, called at src/Darcs/Patch/Ident.hs:277:10 in 
darcs-2.18.5-6c16f972831d2226bab583beffd8387531edab291caba6a3fc0d1e5b14a3c20f:Darcs.Patch.Ident

Attachments

• htam-darcs-bug.tar.lz

Follow-up message by lemming that created a new issue2739 instead:

I remember I created htam-4.16 by pulling some patches from htam, answered 
"w" to most patches and only "y" to the last two ones.

When I saw this report, I was ready to dismiss it as being caused by the 
well-known problems in darcs-2 patch semantics. However, looking closer at 
the two repos reveals that there are neither conflictors nor duplicates on 
either side! I am investigating what happens here.

After instrumenting darcs to print information about the common patches that 
it cannot commute (see patch2454), I was able to narrow the problem down. It 
appears that in htam-4.16 (but not in htam) we have this patch:

patch b5e1fcb06ca81dc05a006a987dd3b5bd28340c52
Author: haskell@henning-thielemann.de
Date:   Mon Jan 20 00:34:31 CET 2025
  * Fourier.transform_bijective, transform_transform
  PrimitiveRoot.root_pow_top_sq, primitive_root_inv
  Fin.natCast_mul

In both repos we have

patch 7d7eb29c3f49a107ea8b89b8ec8cab08d1f3f77b
Author: haskell@henning-thielemann.de
Date:   Tue Jan 21 19:24:18 CET 2025
  * Vector.Linear: module extracted from Fourier.Basic

Now, in htam-4.16 the latter (7d7eb29c) depends on the former (b5e1fcb0), 
while obviously this is not the case in htam which doesn't even have 
b5e1fcb0.

The first step in solving this riddle will be to understand why exactly the 
two patches do not commute in htam-4.16.

I found out that while the two branches of the project do not (yet) 
contain Duplicates or Conflictors, Duplicates do appear when we merge 
them. This can be seen by first obliterating 7d7eb29c (including patches 
that depend on it), which depends on the duplicates, which causes the 
problem.

So this is indeed the well-known fundamental problem with the darcs-1 and 
darcs-2 patch semantics and the main reason why both are unsound; and the 
reason is that conflicted patches (I am including darcs-2 Duplicates 
here) do not track prim patch identities.

As for mitigation, the only possible way I can see is to change the 
algorithm for merging patch sequences, so that when commuting common 
patches to the tail fails, we still try to merge what remains, even 
though there may be residual common patches in the two branches. To make 
this work, we need a more robust version of merge (for single patches 
with identity), such that merging a patch with itself is not an error:

  -- | Like class 'Merge' but defined for every input.
  class Merge p => RobustMerge p where
    robustMerge :: (p :\/: p) wX wY -> (Maybe2 p :/\: Maybe2 p) wX wY

We then have to replace the generic Merge instance for FL with

  instance (Indent p, RobustMerge p) => Merge (FL p)

where we iteratively apply robustMerge, and afterwards filter out the 
"null patches" using

  -- | Throw out the 'Nothing2's, keep what's in the 'Just2's.
  catMaybesFL :: FL (Maybe2 p) wX wY -> FL p wX wY
  catMaybesFL (Nothing2 :>: ps) = catMaybes2 ps
  catMaybesFL (mp :>: ps) = mp :>: catMaybes2 ps

I will give this a try and see if this allows the merge to succeed.

I have implemented a mitigation (patch2455) that seems to work i.e. it 
allows me to push and pull between your two repos. This is currently 
pending comments from Ganesh.