Alvaro Herrera <alvhe...@2ndquadrant.com> writes: > Tom Lane wrote: >> Alvaro Herrera <alvhe...@2ndquadrant.com> writes: >>> I believe it's possible to mechanically rebase a patch over an indent >>> run of the underlying branch with half a dozen commands or less. +1 for >>> reindenting all branches before each minor release, FWIW.
>> Yeah? Can you show an example? > I *think* this should work: > git checkout C > pgindent tree > git commit # yields I' > git diff I I' > C' > git checkout I > git apply C' > I spent a few minutes looking for a nontrivial patch to test this on, > couldn't find one; but the key is that you must be able to run pgindent > on your own using the same rules that Bruce's run would. OK. So agreed, the blocking issue here is whether pgindent is conveniently available to every patch submitter. Right now, it would certainly be charitable to describe installing it as a PITA. I think what we'd need to do is (1) include fully patched sources in our git tree, and (2) build them by default (but not install them, probably) so that we can flush out any portability issues. I think it's too late to consider doing that for 9.5, but maybe we could do it after the branch. Another issue is whether there's a copyright problem if we include modified BSD indent sources in our tree. I wouldn't think so but we better check exactly how it's licensed. We'd also want a more mechanical way of obtaining the right typedef list to use. Although it probably couldn't be totally mechanized, because if your patch adds new typedefs you'd want to manually add those names to the list being used. Maybe there should be an optional local typedef list separate from the automatically generated file. I guess in the scenario you're describing, the most helpful thing would be if the pgindent commit put the typedef list it had used into the tree, and then we just use that (plus manual additions) when generating the I' commit. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers