martingjaldbaek
commented
3 years ago Hey Joshua, thanks for the heads up! The "Should not be doing an octopus" error means there was a merge conflict, which your error output confirms. As far as I know that conflict would still be there if the branches were merged one at a time, so I'm not sure if adding an option to not do an octopus merge (i.e. merge the branches one at a time instead) would actually help anything here.
When looking at your error, I can see that the merge conflict is in site/composer.lock. That makes sense, since the most likely way for two different Dependabot PRs to have a conflict is if the resolved 2nd hand dependencies from two different PRs end up resolving to the same lines in the .lock file - which I think might not be too uncommon in frameworks with modular components that share a lot of dependencies. Unfortunately I'm not sure there's really a good way to solve this from git - the "correct" solution would be to add the dependencies together, and then let the package manager sort out the right way for the .lock file to look. That's probably also what Dependabot does if a rebase fails. But unfortunately I think that means that this is just a limitation to this approach, where it merges unrelated PRs together just fine, but closely related PRs will tend to cause conflicts. For a scenario like that, I think the only real solution is to use a dependency update service that will group the PRs for you (I've heard that https://depfu.com/ has that as an option).
Finally, an idea I'm thinking of is to define a kind of label you could put on PRs that you wanted to exclude from the merge. Unfortunately, I don't think that would help in your case, since I can see from the names of your branches that probably almost all your branches would have merge conflicts.
HonkingGoose
I love the idea of this, however I receive the following error:
I'm using it with
dependabotPRs, status set tofalseon thecombine-prs-branchbranch.Frequently when I merge multiple dependabot PRs in a row, I have to wait for subsequent PRs to rebase before I can proceed with the next. I'm thinking that's somehow related.
Here's the full output: