| From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
|---|---|
| To: | Andres Freund <andres(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: moving from contrib to bin |
| Date: | 2014-12-13 02:11:19 |
| Message-ID: | 548BA047.4080409@gmx.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 12/12/14 11:45 AM, Andres Freund wrote:
> On 2014-12-12 11:42:57 -0500, Robert Haas wrote:
>>> I think the amount of effort a simple renamed directory which wholly
>>> contains a binary creates is acceptable. Just use patch -p4 instead of
>>> patch -p1...
>>
>> That is fine if you are manually applying a patch that touches only
>> that directory, but if the patch also touches other stuff then it's
>> not as simple.
>
> I think backpatchable commits that touch individual binaries and other
> code at the same time are (and ought to be!) pretty rare.
>
>> And I don't know how well git cherry-pick will follow
>> the moves.
>
> Not well if the patch is done in master first.
It does work. I have tried it with the changes I'm working on.
There might very well be limits to the cleverness of these tools, but if
you know of a fundamental reason why this would be a problem, let's
please hear it.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2014-12-13 02:17:00 | Re: moving from contrib to bin |
| Previous Message | Alvaro Herrera | 2014-12-13 02:09:46 | Re: On partitioning |