From: | "Markus Wanner" <markus(at)bluegap(dot)ch> |
---|---|
To: | "Nicolas Barbier" <nicolas(dot)barbier(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: PostgreSQL Developer meeting minutes up |
Date: | 2009-06-08 14:17:29 |
Message-ID: | 20090608161729.23933argdds1usmx@mail.bluegap.ch |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
Quoting "Nicolas Barbier" <nicolas(dot)barbier(at)gmail(dot)com>:
> ISTM that back-patching
I take this to mean "back-patching by cherry picking".
> a change to a file that wasn't modified on the
> back-branch leads exactly to merging a change to a (file-wise)
> ancestor?
Regarding the file's contents - and therefore the immediately visible
result - that's correct. However, for a merge, the two ancestor
revisions are stored, where as with cherry-pinging this information is
lost (at least for git).
So, trying to merge on top of a cherry-pick, git must merge these
changes again (which might or might not work). Merging on top of
merging works just fine.
Regards
Markus Wanner
From | Date | Subject | |
---|---|---|---|
Next Message | Dimitri Fontaine | 2009-06-08 14:33:09 | Re: pg_migrator issue with contrib |
Previous Message | Alvaro Herrera | 2009-06-08 14:12:18 | Re: Partial vacuum versus pg_class.reltuples |