* Marko Kreen <markokr@gmail.com> [090603 11:12]:
> Well, thats good to know, but this also seems to mean it's rather bad
> tool for back-patching, as you risk including random unwanted commits
> too that happened in the HEAD meantime. But also, it's very good
> tool for forward-patching.
It doesn't "pull in commits" in the sense that darcs does... But rather,
its more like "the patch changes $XXX in $file, but that $file was
really $old_file at the common point between the 2 commits, and
$old_file is still $old file in the commit I'm trying to apply the patch
to".
It looks at the history of the changes to figure out why (or why
not) they apply, and see if they should still be applied to the same
file, or another file (in case of a rename/moved file in 1 branch), or
if the changed area has been moved drastically in the file in one
branch, and the change should be applied there instead.
> But my point was not about that - rather I was pointing out that
> this "patch-commute" will result in duplicate commits, that have
> no ties in DAG.
Yes. That's a cherry-pick, if you want a merge, you merge ;-) But
merge carries the baggage of expectation that *all* changes in both
parents have been combined.
--
Aidan Van Dyk Create like a god,
aidan@highrise.ca command like a king,
http://www.highrise.ca/ work like a slave.