See also Github PR: https://github.com/wmde/cypress-wikibase-api/pull/1/files

I do get an error for that spec locally, but it's a slightly different one, in case that helps:

Thanks for the nudge. I've created the re-revert now - would need @hashar to take a look and approve that. I've abandoned the other change.

I could be on board with closing this ticket if there is an alternative ticket that outlines some concrete, pragmatic and likely-to-be-worked-upon path for moving away from master branches in our projects in the long term. I agree that new projects only is not the whole solution, but I imagine most solutions we come up with will involve some uncomfortable period where some repos have a main branch and some have a master and we're not sure which is which. We might be able to make that a bit less painful with something like a symbolic ref.

Ah yeah. I was checking with an EntitySchema. I didn't try on an item.

Yeah - I changed my mind and +2'd it in the end because there were other changes that needed to go into EntitySchema and I didn't want to have the component blocked for a week.

In my local testing, I can reproduce the issue with EntitySchema, undo/restore and temp accounts. But it seems like with @Lucas_Werkmeister_WMDE's changes in T356148, this works fine. Is that also what you would expect / experience, Lucas?

Thanks for the clarification, and sorry for giving everyone the run-around here. This is my first time trying to contribute to an upstream project on our gitlab, and the workflow I am used to from the Github repos that WMDE maintains is to push feature branches to the upstream and make PRs from the feature branches. If the expected workflow for Gitlab is for every developer to maintain personal forks, I can work with the existing permissions that I have.