Tom Lane wrote: > Robert Haas <robertmh...@gmail.com> writes: > > Yeah, but those advantages could also be gained by putting the > > pgindent tree on git.postgresql.org in a separate repository. Having > > it in the same repository as the actual PostgreSQL code is not > > required nor, in my opinion, particularly desirable. > > It adds an extra step to what a developer has to do to get pgindent > up and running, so it doesn't seem to me like it's helping the goal > of reducing the setup overhead.
I favor having indent in a separate repository in our Git server, for these reasons 0. it's under our control (so we can change rules as we see fit) 1. we can have Piotr as a committer there 2. we can use the same pgindent version for all Pg branches I'm thinking that whenever we change the indent rules, we would re-indent supported back-branches, just as Tom's proposing we'd do now (which I endorse). We wouldn't change the rules often, but say if we leave some typedef wonky behavior alone for now, and somebody happens to fix it in the future, then the fix would apply not only to the current tree at the time but also to all older trees, which makes sense. Now, there is a process that can be followed to update a *patch* from an "pre-indent upstream PG" to a "post-indent upstream PG", to avoid manual work in rebasing the patch past pgindent. This can easily be used on branches that can be rebased, also (since they are essentially just a collection of patches). One problem that remains is that this doesn't apply easily to branches that get merged without rebase. I *think* it should be possible to come up with a process that creates a merge commit using pgindent, but I haven't tried. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
