On 2008-06-04, Peter Hercek
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
apfelmus answered this. I might expand on his reply.
There is one thing that git rebase does easily (and correctly) that darcs doesn't do nicely: rewriting history by merging commits "prior" to the head. I put prior in quotes, because darcs doesn't preserve history in the first place. I don't find that a compelling use, as opposed to maintaing topic branches.
I do not know what you mean here. Can you point me to some example?
Letting capitals be commits, and lowercase be trees at the point of these commits. Suppose your history is: A -> B -> C -> D | | | | a b c d And that B somehow doesn't make sense except with the additional changes in C. You don't want to deal with this, or have anyone see B. All it does is clutter up the history. So you want to expunged it from the history. git rebase can rewrite this to A ------> C' -> D' | | | a c d Doing this in darcs would require unrecording B and C, and then rerecording C'. But, if D is in the repo, then it is likely that B and C can't be commuted past it to be unrecorded. (If they can, no problem!) Unrecording D (and possible E, F, G, etc.) lets you do this, but if you then pull it back from another repo, it will depend on B and C, and pull these in, which are now doppelgangers of C'. Not having used darcs 2, I'm not sure if that's still quite so fatal, but it remains bad news AIUI. The bottom line is that darcs is a tool for managing sets of always existing patches. and ordering them lazily, as needed. In particular, no history generally exists, unless each patch depends on exactly one previous. It has a "differential" view of software development, in that the changes, and not the sum at each point matter (though of course, the current sum does matter.) On the other hand, git is a tool for managing (and munging) histories of development in many weird and wacky ways. It has an "integral" view of software development, the changes are lazily derived from the saved state at each point, and are strictly ordered even when they're independent. It can, when needed, work with these changes to accomplish fairly interesting history-altering tasks, but as soon as they're used to construct a new history, they're discarded. (Yes, git uses deltas, but this is "merely" an optimization.) The two models are dual to each other in many ways. -- Aaron Denney -><-