It would be nice if darcs could track history of patches so that we can get safe
amend record and patch reorder in cloned repositories.

A) Amend-record should be safe. This probably means that a hierarchy should be
added to patches. A patch (as seen in darcs log and other UI commands) should be
composed of a sequence of patches so that amending a patch would add the
"amendment" to it and it would not be a problem when the original patch was
already pushed (the "amendment" would get pushed the next time). It should be
possible to look at components of a patch. Kari Hoijarvi wishes to preserve the
destructive nature of amend-record so that unwanted or sensitive data are not
tracked. So the unsafe amend-record should be kept.

B) Allow patches which depend on each other to commute (by adding conflict
resolution). So if we have patches Porig Qorig in repository, we could change
their order to Qnew Pnew where Qnew would be actually a sequence like (Porig
Qorig Porig^') and Pnew would be (Porig Qorig Qnew^). These Qnew and Pnew should
replicate to cloned repositories without problem in a similar way as in option A
- as a patch to patch (maybe by transferring Porig^' and some associated info).
  Order P Q means P is first in the repository.
  ^ stands for inverse patch.
  ' stands for the patch on the opposite side of square.

This request represents (at least I believe so) a superior alternative to
mercurial queues or git rebase.

Note that users may wish to amend what was originally recorded as one named 
patch (composed of N primitive patches) into M named patches, possibly 
containing additional primitive patches, and possibly outright dropping 
primitive patches from the collection.

This would be a very welcome feature, IMHO.

That would be a superset of git's ability to merge patches which are older than
head to one patch. Aaron Denney discussed patch reordering and the "old patch
merging" feature with me on haskell-cafe:
http://www.haskell.org/pipermail/haskell-cafe/2008-June/043882.html
Linus argued (sorry, do not remember the link) about usefulness of merging
patches before pushing them upstream. Something along the lines that upstream
reviewers should not be concerned with elemental patches only with the final
result (the final patch) ... that supports your addition to the wish too.

I get the impression that msg5093 and msg5111 seem to be talking about a
different feature (issue1560).

As for the original message, I think I understand (A) but not (B).  What do we
mean by "safe patch reorder"?  Doesn't commutation already give us 'safe' patch
reordering?  Perhaps it has something to do with changing the dependencies of an
amended patch?

Phercek: perhaps you could comment?

Right, msg5093 and msg5111 are mentioned explicitly in issue1560 and in this
sense they may belong more to issue1560, but they are related to this one as
well. The point is that solution to both could use a hierarchy of patches if we
want to preserve safe replication. Although it seems that this ticket does not
need the hierarchy to be browsable/visible at the UI level but it would be very
handy so that user can see how the patches were amended. On the other side at
least some concerns of issue1560 could by done without patch hierarchy if the
lower level would be the level of hunks only but this would not be comfortable
for bigger patches.

There would be actually two histories in darcs:

1) history of (partially ordered) top level patches as we see it now

2) history of a patch (what amendments were done to a patch) - so one could see
what patches is a top level patch composed of

Although msg5111 may not belong to this ticket that much the discussion on
haskell-cafe belong to this ticket.
http://www.haskell.org/pipermail/haskell-cafe/2008-June/043882.html

Add B: By "safe patch reorder", I mean that when I have patches Porig Qorig,
which are already replicated to remote repositories, I still can reorder them to
Qnew Pnew. And I can do it despite Qorig depending on Porig. And these new Qnew
Pnew would get correctly replicated to the remote repositories without causing
any conflicts there. Note that this reordering of patches makes sense in darcs
only when there is a dependency (i.e. reordering means that a user provides a
conflict resolution from which Porig^' and Qnew^ can be made).
Since darcs should know about patch hierarchy, the only thing which needs to be
replicated later again is Porig^' and Qnew^ and the information that Porig
changes to Pnew with hierarchy (Porig Qorig Qnew^) and Qorig changes to Qnew
with hierarchy (Porig Qorig Porig^').

OK, I think this sort of change is deep enough that we're going to have to put
it off for beyond Darcs 2.  Adding Ian to nosy in case he's interested.  

Feel free to bring this up on the mailing list at some point if you feel it
needs some discussion.

Seems like this depends on issue1613

(but leaving deferred instead of waiting-for; the former says "let's not
think about this now" whereas the latter says "we're thinking about it,
but we can't act until that pre-requisite is fulfilled)