> That is: > 1. Whenever a patch is pushed on master on the main repo a process kicked > off (or maybe wait 5 minutes to coalesce multiple patches if there are) > 2. This process checks out master, and runs pgindent on it > 3. When done, this gets committed to a new branch (or just overwrites an > existing branch of course, we don't need to maintain history here) like > "master-indented". This branch can be in a different repo, but one that > starts out as a clone of the main one > 4. A committer (any committer) can then on regular basis examine the > differences by fetch + diff. If they're happy with it, cherry pick it in. > If not, figure out what needs to be done to adjust it.
Sounds good -- for branch master.
So mostly for testing, I've set up a job that does this.
Basically it runs every 15 minutes and if there is a new commit on master it will rebase onto the latest master and run pgindent on it. This then gets pushed up to a separate repo (postgresql-pgindent.git on git.postgresql.org), and can be viewed there.
(or decorate as wanted to see for example a raw patch format)
If a committer wants to use it directly, just "git remote add" the postgresql-pgindent.git and then cherry-pick the branch tip into your own repository, and push. Well, actually that will right now fail because the commit is made by "Automatic pgindent" which is not an approved committer, but if we want to do this as a more regular thing, we can certainly fix that.
Note that the only thing the job does is run pgindent. It does not attempt to do anything with the typedef list at this point.
