Hi Jed, > > So, so I will continue quickly along the following path: > -> Bring sources to a clean state > -> Provide simple and robust guard scripts (pre-commit/pre-push) > > > Note that pre-commit cannot be run on a user's machine without their > assistance (configuring hgrc). (Doing so would be a huge security > vulnerability.)
Yes, I'm aware of that. Since we have to update hgrc for the BuildSystem anyway, it's 'just another line'. If we reject the commit server-side, the author will > have to edit their history (requires enabling an extension unless it's > the last commit). Since it's a hassle to go back and fix the history, > hopefully it will teach developers to enable the commit hooks. Eventually we can come up with a hook that aggregates multiple commits, i.e. the user only needs to add a follow-up commit fixing the violation rather than fiddling with the history. > -> Configure uncrustify such that it reports violations (nightly) > -> Document user-specific uncrustify configs > > > Until someone finds a way to do this with Hg, I think this last point > would only be meaningful to git users. Albeit not ideal, I think it's reasonable to - either wait for a similar way of doing that with Mercurial, or - use gitifyhg for users who insist on using custom non-PETSc-style. This is a fairly low hurdle compared to what you get for it. Best regards, Karli
