On Mon, Sep 24, 2012 at 10:21 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
>> I wanted to refactor the highly redundant flex and bison rules
>> throughout the source into common pattern rules. (Besides saving some
>> redundant code, this could also help some occasionally flaky code in
>> pgxs modules.) The only outlier that breaks this is in plpgsql
>
>> pl_gram.c: gram.y
>
>> I would like to either rename the intermediate file(s) to gram.{c,h}, or
>> possibly rename the source file to pl_gram.y. Any preferences or other
>> comments?
>
> Hmmm ... it's annoyed me for a long time that that file is named the
> same as the core backend's gram.y. So renaming to pl_gram.y might be
> better. On the other hand I have very little confidence in git's
> ability to preserve change history if we do that. Has anyone actually
> done a file rename in a project with lots of history, and how well did
> it turn out? (For instance, does git blame still provide any useful
> tracking of pre-rename changes? If you try to cherry-pick a patch
> against the new file into a pre-rename branch, does it work?)
git handles renaming just fine with cherry-picks, no special options
necessary. (Well, there are probably corner cases, but it's code,
there are always corner cases!)
For "git log", you'll want to add the --follow parameter if you're
asking for the history of a specific file or directory beyond a
renaming event.
git blame will show you the commit that renamed the file, by default,
but then you can request the revision prior to that using the commit
hash || '^', for example. "git blame 2fb6cc90^ --
src/backend/parser/gram.y" to work your way back through history.
--
Dan Scott
Laurentian University
