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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
