Imagine you have

• Branch A (forked off of main branch) with commits A, B, C
• Branch B (forked off of branch A at commit C) with additional commits D, E, F

If you then create two pull requests, one for each branch, then pull request for branch A contains commits A, B, C and pull request for branch B contains commits A, B, C, D, E, F. So you end up with two pull requests sharing some commits. This creates quite some noise during review of pull request B in OneDev. This situation can for example happen if A, B, C implement a new feature and D, E, F, already use that new feature.

In other products (e.g. Gerrit) this situation is detected and if you look at pull request B you would only see changes of commits D, E, F and a note that this pull requests depends on pull request A. In that case you can not merge pull request B unless you have first merged pull request A. If pull request A is updated (commits added or commits replaced via force push or branch has only been rebased on main branch to keep it up to date) then pull request B needs to be rebased as well in order to be able to merge it.