From: | Marko Kreen <markokr(at)gmail(dot)com> |
---|---|
To: | Aidan Van Dyk <aidan(at)highrise(dot)ca> |
Cc: | Magnus Hagander <magnus(at)hagander(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, Greg Stark <stark(at)enterprisedb(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Markus Wanner <markus(at)bluegap(dot)ch>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: PostgreSQL Developer meeting minutes up |
Date: | 2009-06-03 15:28:34 |
Message-ID: | e51f66da0906030828v1126fdb8h1cb79b12d14101a3@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 6/3/09, Aidan Van Dyk <aidan(at)highrise(dot)ca> wrote:
> * Marko Kreen <markokr(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Kolb, Harald (NSN - DE/Munich) | 2009-06-03 15:28:53 | Synchronous replication: status of standby side |
Previous Message | Aidan Van Dyk | 2009-06-03 15:25:31 | Re: PostgreSQL Developer meeting minutes up |