On Mon, Sep 24, 2012 at 10:21 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Peter Eisentraut <pete...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers