this is a critical reason why git makes sense to me, cause all non trivial code changes conflict, and then need to be resolved with understanding of the underlying code.

the only way to reorder these in git is with rebase, but that is flagged as a dangerous tool, and with good reason.

if darcs can find a way to do this it would really be worth switching to, but if not then it would fall short in it's claim of safely being able to reorder patches. doing so behind the scene automatically would really worry me about code integrity.

Don't forget that there are two kinds of dangerous in a vcs: code-dangerous and repo-dangerous: stuff that can give you a working repo containing code that does not work, and stuff that can give you a non-working repo, or changes between repos that are tracked inconsistently. Cherry-picking (i.e. creating a version that has not been seen by a developper before) is as code-dangerous with darcs as it is with git. Commit and merge are also code-dangerous. On the other hand, in darcs it is not repo-dangerous: you don't have to worry about merges versus cherry-picks, a repo's final state is only defined by which patches you've pulled. This is the kind of consistency that git does not give, and that makes git rebase repo-dangerous. darcs' cherry-pick is no more dangerous than merge, while git's is in fact more dangerous.

It is quite common to have people come to #darcs asking how to reorder patches. The answer to that is "why would you want to do that?" To darcs, the order in which the patches are stored in the repository is a transparent implementation detail, and there's no command to change that. Darcs users are not constantly reordering patches, they're just enjoying a bit more freedom on pull. In general, if you don't use commands marked as unsafe such as unpull, each repository is honest about the order in which it pulled patches: darcs will simulate patch reordering to compute merge results, but won't change the order of patches in the repository.

There's one "patch theoretical" thing which git does better than darcs (and a lot of practical things), which is that it tracks more explicitely which stuff was pulled from where when. That information is neglected by darcs, which cares more about when stuff was originally written, and it should be tracked somewhere. Still, this seems easier to add to darcs than adding darcs' freedom of workflow to git, for which, as far as I can tell, you'd have to embrace the patch-centric view of darcs.

Yet, it would be cool if I could explicitly tell Darcs about patch dependencies, maybe at `record` time. It's no guarantee (I could forget some), but it could help avoid screw-ups when cherry picking.

You can, you just use `darcs record --ask-deps`. There's also the idea of allowing some kind of test to infer more dependencies for you at record time.

thanks, this makes a lot more sense to me explained this way :)