Peter Hercek wrote:
But what about this git rebasing option? How to do it more easily (than the solution I know and I described it later) in darcs?
using "git-rebase --onto master next topic" to get from: o---o---o---o---o master \ o---o---o---o---o next \ o---o---o topic to:
o---o---o---o---o master | \ | o'--o'--o' topic \ o---o---o---o---o next
This is the reason why I mentioned reordering depending patches AB to BA (with manual conflict resolution) would be needed in darcs to support (I believe a better) alternative to git rebase.
I don't understand (probably because I haven't use either dvcs). Either the changes in the next->topic path don't depend on the changes in the fork->next path. Then, the patches commute and it's no problem for darcs. Or the next->topic path relies on features from next that are not present in master . But then, you're screwed anyway and should merge some parts from next into master so as to advance the point where master and next fork. o---o---o---o---o master \ x---x---o---o---o next \ o---o---o topic (Of course, you don't actually advance the fork but rather add patches at the end of master . Hm, set of patches semantics seem to be a lot nicer here anyway. To me, the whole point of rebasing seems to be to somehow bring set semantics into the tree semantics.) Regards, apfelmus