Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> Tom Lane wrote:
>> Alvaro Herrera <alvherre@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
