3 March 2026: Removing the bypass option for 24 hours as a trial period. The goal is to uncover any remaining issues before we remove the bypass option permanently.
31 March 2026: Removing the bypass option permanently. This date could be moved back if we uncover issues during the trial period and need more time to address them.
Note that this change means you will need to create a PR rather than pushing to main directly, but we do not require approval prior merging the PR. If you rely on pushing changes to main directly, please try the new git-llvm-push script which automates the workflow of creating and merging the PR. If you run into any problems with the script, please file an issue and we’ll look into it as soon as possible.
The primary goal of the trial period is to identify bots and other kinds of automated workflows that rely on direct commit access and we hope that 24 hours would be sufficient.
Since there were no objections, I removed the bypass rule for the main branch and will restore it after 24 hours. Please let me know if you encounter any issues.
A lot of long-lived PRs will have one reviewer request changes at the start and then never come back. Is the new expectation that we hunt them down before we can merge?
I think it’s a major technical vulnerability that any of 3k+ llvm members can block PR indefinitely.
A reviever can suddenly dissapear due to any personal reasons and at least maintainers should be able to “bypass merge”. It looks like a topic for another RFC.
Since this behavior was not anticipated and not discussed previously, we need to do that and get consensus/understanding on it, prior to rolling this change out again.
However, after I’ve looked into how this works a bit: I actually think it’ll be a good change for LLVM. It is not a hard block on submit (that would, indeed, be terrible for us!). Rather, anyone who has write access may dismiss the review, if they wish, without waiting for the original reviewer to re-review – but you must dismiss it with an explicit action, writing a comment as to why you’re doing so, before you can submit.
Typically, I would expect someone to do so if believe they’ve resolved the issues the reviewer had with the change, and the original reviewer has not responded back in a reasonable period of time. We might need to add that expectation to our developer policy – without an explicit permission, people might be unnecessarily scared of pressing the “dismiss review” button, or might never find the button!
I used git-llvm-push for the first time. My branches are origin and local. I had to pass this in manually, but I feel like the tool should at least be able to detect the LLVM repository. Detecting the user’s branch would be ambiguous, but you could let the user select one of multiple in the default case. The current failure mode for this isn’t very intuitive, also I’m thinking it would be nicer if the tool queried you for an auth token instead of requiring and environment variable. If gh is in the path you could probably just use that directly.
Error running command: git rev-list --reverse upstream/main..HEAD
--- stderr ---
fatal: ambiguous argument 'upstream/main..HEAD': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
Returning to original branch: TestFix
Traceback (most recent call last):
File "llvm/utils/git-llvm-push", line 704, in <module>
main()
~~~~^^
File "llvm/utils/git-llvm-push", line 698, in main
automator.run()
~~~~~~~~~~~~~^^
File "llvm/utils/git-llvm-push", line 542, in run
commits = self._get_commit_stack()
File "llvm/utils/git-llvm-push", line 436, in _get_commit_stack
result = self.runner.run_command(
["git", "rev-list", "--reverse", f"{target}..HEAD"],
...<2 lines>...
read_only=True,
)
File "llvm/utils/git-llvm-push", line 109, in run_command
raise e
File "llvm/utils/git-llvm-push", line 91, in run_command
return subprocess.run(
~~~~~~~~~~~~~~^
command,
^^^^^^^^
...<4 lines>...
env=env,
^^^^^^^^
)
^
File "/usr/lib/python3.14/subprocess.py", line 577, in run
raise CalledProcessError(retcode, process.args,
output=stdout, stderr=stderr)
subprocess.CalledProcessError: Command '['git', 'rev-list', '--reverse', 'upstream/main..HEAD']' returned non-zero exit status 128
Also, merging this gave me a “[llvm/llvm-project] PR run cancelled: CI Checks” email which I’d prefer not to need to deal with.
By branch here you mean remote? Given we can’t know statically in the case of multiple non llvm/llvm-project remotes which remote to choose, I’m not sure we want to get into the business of choosing remotes. I’ve been planning to make the tool read from a git config section that I think would solve this problem though.
The failure messages could definitely be improved in this case. Automatic token querying also makes me a bit nervous, but pulling in from gh could maybe be another config option.
I don’t think there is anything we can do about this.
What I mean is that we should be able to detect what the script currents assumes is upstream/ by checking for llvm/llvm-project. The others could be a drop-down selection similar to how gh pr create will do it, but I don’t know how much effort people want to put into making this script user friendly.
This is quite unfortunate if so, I tended to use direct merges to avoid email spam like this.
A git config approach that lets you specify the options once I still think is a better solution. It’s one and done versus needing to select every time you want to push a commit. Of course we could look at supporting both, but that’s additional effort that might be better spent elsewhere. If documentation/failure messages can point at the git config solution, I think that would probably suffice.
