[keyle]

    Stuff happens in the wrong order. You know the PR. Commit 1: 'Feature.' Commit 2: 'fix.' Commit 3: 'fix.' Commit 4: 'actually fix.' Commit 5: 'please.' Commit 6, made at 11:47 PM on a Thursday: 'asdfasdf'. This person has a family. This person has hobbies. This person is, at this moment, crying. You don't want the feedback loop after the commit you want it before. Let me do an enforced pre-commit hook to run the jobs remotely on the forge and provide the feedback to the user before they push.

Isn't this already totally possible? Or am I thinking subversion?

[rzzzt]

Pre-commit hook running remotely on the forge "before they push" sounds like an oxymoron. How does the code get to the forge for feedback? That's a post-push hook!

[Supermancho]

> Pre-commit hook running remotely on the forge "before they push" sounds like an oxymoron.

I think the implication is that a user doesn't host the CI locally. They are suggesting that there should be? a configuration to call an API to submit the code changes for some part/total CI checking. This is only beneficial for orgs/individuals which somehow rank dev effectiveness based on how messy a branch PR history is and how many times they have submitted code that passes/fails a build. Maybe due to build cost, maybe due to ego.

I understand what they are asking for, but it feels like misusing git or based on some org process rather than normal development flow. I don't understand the point.

[joshka]

yeah, you can have github actions setup on arbitrary pushes to your branches, but there's not a good interface for linking actions to bare commits, and then having conversations etc. The place where that happens is usually a PR.