* Magnus Hagander (magnus@hagander.net) wrote:
> There are many solutions that do such things but that do it in the "github
> workflow" way, which is they do change -> commit -> create pull request,
> and then somebody eyeballs that pullrequest and approves it. We don't have
> PRs, but we could either have a script that simply sends out a patch to a
> mailinglist, or we could have a script that maintains a separate branch
> which is auto-pgindented, and then have a committer squash-merge that
> branch after having reviewed it.
>
> Maybe something like that in combination with a pre-commit hook per above.
So, in our world, wouldn't this translate to 'make cfbot complain'?
I'm definitely a fan of the idea of having cfbot flag these and then we
maybe get to a point where it's not the committers dealing with fixing
patches that weren't pgindent'd properly, it's the actual patch
submitters being nagged about it...
Werll, that's one thing, but what I was thinking of here was more of an automated branch maintained for the committers, not for the individual patch owners.
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.
Step 4 can be done at whatever interval we prefer, and we can have something to nag us if head has been "off-indent" for too long.
This would be the backup for things that aren't indented during patch commit, not other things.