From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Aidan Van Dyk <aidan(at)highrise(dot)ca> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: renaming contrib. (was multi-platform, multi-locale regression tests) |
Date: | 2010-11-11 15:58:59 |
Message-ID: | 15523.1289491139@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Aidan Van Dyk <aidan(at)highrise(dot)ca> writes:
> Can you share what commit you were trying to cherry-pick, and what
> your resulting commit was? I can try and take a quick look at them
> and see if there is something obviously fishy with how git's trying to
> merge the new commit on the old tree...
See yesterday's line_construct_pm() patches. I committed in HEAD and
then did "git cherry-pick master" in each back branch. These all worked,
which would be the minimum expectation for a single-file patch against
a function that hasn't changed since 1999. But in the older branches
it bleated about shutting off rename detection because of too many files
(sorry, don't have the exact message in front of me, but that was the
gist of it). Not the sort of thing that gives one a warm feeling about
the tool. I've seen this before when trying to use git cherry-pick,
but I forget on which other patches exactly.
Oh, for the record:
$ git --version
git version 1.7.3
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2010-11-11 16:08:01 | Re: renaming contrib. (was multi-platform, multi-locale regression tests) |
Previous Message | Marti Raudsepp | 2010-11-11 15:28:11 | Re: renaming contrib. (was multi-platform, multi-locale regression tests) |