Re: PostgreSQL Developer meeting minutes up

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