This should fix the problem with commuting in pull --reorder
I inspected the code and I think it would also have affected
apply --reorder and the corresponding rebase commands, and they
should all also be fixed by this.

I also changed the test so it doesn't inspect repo internals,
which should hopefully make it more future proof.

1 patch for repository darcs-unstable@darcs.net:screened:

Mon Mar  2 19:46:31 GMT 2015  Ganesh Sittampalam <ganesh@earth.li>
  * resolve issue2432: use the merged version of the local patches
  
  The previous code gave a false sense of security in its use of witnesses
  on the Repository type, because those can be implicitly mutated by
  operations on the repository but the Repository value with its old
  witnesses is still available for use.
  
  The bug was that tentativelyReplacePatches should be passed the replacement
  patches, as it just adds them to the repository at the end after commuting
  out the previous versions. So when doing pull/apply --reorder, we need
  to pass in the local patches merged with the remote patches, rather than
  in their original form.
  
  I reworked the code so that the witnesses are correct, which provokes
  a type error, and fixed the error by changing merge2FL to return both the
  merged remote patches and the merged local patches so the latter can be
  passed in to tentativelyReplacePatches.

Attachments

• patch-preview.txt
• resolve-issue2432_-use-the-merged-version-of-the-local-patches.dpatch
• unnamed

Review:

* test changes: ok

* in Darcs.Patch.Depends:
    * the change in mergeThem is just to adapt to the new signature of
merge2FL
    * merge2FL: we now return the complete upper (or lower, depending on
the piece of documentation) part of the "merge diamond". This will
enable us to "use the merged version of the local patches" when bringing
them at the top of our history when doing `pull --reorder`.

* in Darcs.Repository.Merge:
    * the type of 'applyps' (thus 'doChanges') is changed so that it
returns a repository with the correct witnesses. Also we take into
account the repository yielded by (repeated) applications of mapAdd.
    * also it makes sense to run the reorder code only if (mc ==
MakeChanges). Does not change anything concretely now (since the
commands where this fails are unrevert and rollback, which do not accept
--reorder), but it makes more sense when reading the code.

Accepted!