On 6/3/09, Aidan Van Dyk <ai...@highrise.ca> wrote: > * Marko Kreen <mark...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
