Bug 260624 – [git-webkit] Pushing a branch to a secure remote prevents it from being pushed publicly

• Status: RESOLVED
• Resolution: WONTFIX
• Component: Tools / Tests

[Elliott Williams]

I have a second machine configured as a "secure" remote, so that I can push branches I'm working on to it for testing.

If I push any public branch (i.e. a development branch off `main`) to this remote, I can no longer push the branch publicly. For example:

	> git push bolero eng/dont-mutate-sdk-headers-2 -f
	Pushing to bolero, which is classified as a secure remote
	…
	
	# test test test, now it's time to open a PR
	
	> git webkit pr --no-rebase --no-add
	…
	Pushing to fork, which is classified as a public remote
	Verifying commits in 'default' mode
	Attempting to push 1 batch of commits to fork...
	'181f4418c3a3' comes from a more secure remote than 'fork'
	error: failed to push some refs to 'https://github.com/emw-apple/WebKit.git'
	Failed to push 'eng/dont-mutate-sdk-headers-2' to 'fork' (alias of 'https://github.com/emw-apple/WebKit.git')
	Your checkout may be mis-configured, try re-running 'git-webkit setup' or
	your checkout may not have permission to push to 'https://github.com/emw-apple/WebKit.git'

From what I can tell, git-webkit should care about the *content* of the branch, not its presence on other secure remotes. If I delete my tracking branches:

	> git branch -r --contains eng/dont-mutate-sdk-headers-2 | xargs git branch -dr

then I can push successfully.

[Radar WebKit Bug Importer]

<rdar://problem/114719734>

[Jonathan Bedard]

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