Re: renaming contrib. (was multi-platform, multi-locale regression tests) - Mailing list pgsql-hackers

From Marko Kreen
Subject Re: renaming contrib. (was multi-platform, multi-locale regression tests)
Date
Msg-id AANLkTi=Duxx06tUnrmh2VOwnnOOOmAdMt_mMZtzyFVne@mail.gmail.com
Whole thread Raw
In response to Re: renaming contrib. (was multi-platform, multi-locale regression tests)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Thu, Nov 11, 2010 at 6:08 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Marti Raudsepp <marti@juffo.org> writes:
>> On Thu, Nov 11, 2010 at 17:24, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Given that we have, in fact, never renamed any files in the history of
>>> the project, I'm wondering exactly why it thinks that the number of
>>> potential rename/copy targets isn't zero.
>
>> Because git doesn't do "rename tracking" at all -- a rename operation
>> is no different from a delete+add operation. Instead it tracks how
>> lines of code move around in the tree:
>> https://git.wiki.kernel.org/index.php/GitFaq#Why_does_git_not_.22track.22_renames.3F
>
> Hmmm ... so rename tracking is O(N^2) in the total number of patches
> applied, or lines patched, or some such measure, between the branches
> you're trying to patch between?  Ugh.  Doesn't sound like something
> we want to grow dependent on.

No, it's dependant on files changed between two trees.

It does not analyze history when doing rename tracking.

Default limit is 200.  It should be easy to calculate whats needed for Postgres.

--
marko


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: MULTISET and additional functions for ARRAY
Next
From: Dave Page
Date:
Subject: Re: improved parallel make support