hesam-oxe commented on PR #11077: URL: https://github.com/apache/seatunnel/pull/11077#issuecomment-5646987712
@DanielLeens I have to respond to the authorship claim directly, because as framed it implicates me, and the record does not support it. **The fork-side accusation is disproven by the push record.** GitHub PushEvents record the authenticated actor that transported each push, and that metadata is not settable via local `git config`: | Commit | Authored | PushEvent on hesam-oxe/seatunnel | Actor | | --- | --- | --- | --- | | `343205b` "[Chore] Retrigger CI" | 2026-09-07T13:47:53Z | 2026-09-07T13:47:59Z | **@davidzollo** | | `26dd37e` "[Chore] Retrigger CI" | 2026-09-07T19:42:53Z | 2026-09-07T19:42:58Z | **@davidzollo** | Reproducible with `GET /repos/hesam-oxe/seatunnel/events`: **every** push to the fork between 2026-08-22 and 2026-09-08 was transported by @davidzollo via maintainer edits (`maintainer_can_modify` is enabled on this PR; he has himself announced his pushes to this branch in this thread, e.g. the 2026-09-02 force-push note). My last push to this fork was **2026-08-21**, and the fork's collaborator list contains exactly one account — mine (`GET /repos/hesam-oxe/seatunnel/collaborators`). So there is no room for "fabricated by the fork owner or a collaborator": nobody on the fork side touched this branch after 2026-08-21. The two commits arrived on an upstream maintainer's authenticated push, with commit metadata that was set locally wherever they were created — the `Co-Authored-By: Claude Sonnet 5` trailer suggests an agent workflow, and whoever runs that workflow knows which git identity its machine carries. **One technical correction to the reasoning in your comment:** `gh api repos/hesam-oxe/seatunnel --jq .permissions` reports *fork-level* permissions only; it does not reflect maintainer-edit access over a PR ref. As a SeaTunnel committer with maintainer-edit rights here, a `push: false` from that endpoint does not establish that your account "genuinely could not have pushed" either. I don't say that to trade accusations — I'm not arguing from permissions at all. I'm arguing from the push events, which are authoritative about who pushed, and they name neither of us. **Where this leaves us:** the claim that someone with fork access fabricated these commits is contradicted by an authenticated record. Since you've flagged this twice and asked that it not be merged past without acknowledgment — this is that acknowledgment, with receipts. Please retract the fork-owner accusation and post the correction so this stops hanging over the review. @davidzollo — could you confirm where the two "[Chore] Retrigger CI" commits originated, and which git identity was configured on the machine/agent that created them? That closes the loop cleanly. To be clear: I agree with your underlying principle that commit attribution on this PR should be trustworthy — which is precisely why the answer should follow the evidence rather than a theory. Once this is corrected I'm happy for the discussion to go back to where it belongs: the code. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
