I've been running into this myself. I think the problem is that the "should be marked as WIP" logic is based on whether a branch has an associated gerrit issue (_GerritChangelistImpl.GetIssue(), resolving to a 'gerritissue' property on the branch), but `git cl upload --no-squash` may not set an issue on the branch.

https://chromium.googlesource.com/chromium/tools/depot_tools/+/78ce24e/git_cl.py#3039

Here's the .git/config section for a branch of mine that this bug affects:

  [branch "refactor"]
	remote = origin
	merge = refs/heads/master
	base = 6c9bd10a24adef99f40641ebcef859e4427ab1a9
	base-upstream = refs/remotes/origin/master
	last-upload-hash = e8403694267b5ac400cc1305b79c0db8d7a9b584

This branch is three commits ahead of origin/master.

Maybe the WIP flag could be set on the absence of last-upload-hash.

Here's a naive patch that works for me, though now I see that a real fix will be tricky if it wants to be able to WIP new commits in a chain while keeping the old ones non-WIP.

Deleted: chromium-770252.patch 1.0 KB

chromium-770252.patch 1.0 KB Download