On 6/3/09, Aidan Van Dyk <aidan@highrise.ca> wrote:
> * 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.
I'm not certain, but I remember using cherry pick and seeing
several commits in result. This seems to be a point that needs
to be checked.
> > 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.
But in forward-merge case it's true.
--
marko