Summary: | [git-webkit] Pushing a branch to a secure remote prevents it from being pushed publicly | ||
---|---|---|---|
Product: | WebKit | Reporter: | Elliott Williams <emw> |
Component: | Tools / Tests | Assignee: | Nobody <webkit-unassigned> |
Status: | RESOLVED WONTFIX | ||
Severity: | Normal | CC: | jbedard, webkit-bug-importer |
Priority: | P2 | Keywords: | InRadar |
Version: | WebKit Nightly Build | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Bug Depends on: | |||
Bug Blocks: | 239082 |
Description
Elliott Williams
2023-08-23 13:23:49 PDT
I'm actually going to mark this one as "behaves correctly". What's actually going on here is that you have a remote that doesn't have a classification, so we consider it to be "secure" when changes are coming from it, but "public" when changes are going to it. By design, `git-webkit` is pretty naive about the content of commits and forbids "promoting" commits from secure remotes to public remotes. There are some situations where this is annoying, but in most cases, this behavior protects contributors from their own (potentially catastrophic) mistakes. There are a couple of work arounds. - Re-run `git-webkit setup`. If the unclassified remote is a GitHub remote, we can compute its security level, which may be "public", which will avoid all of this. (we don't compute security levels during a push because it's a relatively expensive operation) - Rebase your PR. The "promotion" design relies exclusively on hashes, it's really looking for commits landed on a production branch which won't be rebased |