Anne Stellingwerf

That won't be until at least after the conflicts are resolved.

If the push of the onboarding branch fails, maybe the issue should give some explicit guidance on how to manually onboard Renovate, possibly already either pointing to properties to tweak...

Not just the Onboarding PR, @hasanwhitesource, though that would typically be the first instance where we run into the blocking push rules. But the same issue might occur for normal...

You may best look at [this page](https://docs.gitlab.com/ee/user/project/repository/push_rules.html#validate-commit-messages), and the "Validate commit messages" and "Validate branch names" sections in particular. That's a typical example: branch names must be a JIRA ticket...

I'm not sure that we can definitively determine that the push fails because of a Gitlab Push rule. It seems that they've implemented it as a [pre-receive hook](https://git-scm.com/docs/githooks#pre-receive). I imagine:...

Yes, that does make sense, @hasanwhitesource. Maybe keep it simple in the Issue, and clearly refer to richer documentation pages.

No it still splits incorrectly then: ``` DEBUG: packageFiles with updates (repository=astellingwerf/reproduce-renovate-discussion-11438) "config": { "npm": [ { "packageFile": "package.json", "deps": [ { "depType": "dependencies", "depName": "@angular/core", "currentValue": "~11.1.0", "datasource": "npm",...

Here you go: https://github.com/astellingwerf/renovate-issue-11680/pull/1

In a version from this weekend, this issue is not fixed for all pinning. For example, Font Awesome dependencies like `"@fortawesome/react-fontawesome": "^0.1.4"` are still put in a separate branch (see...

Is pinning enabled though?