I’ve found a curious issue with Git repository pull requests. I get different visual diff results when performing a pull request between a repository and an identical fork, vs performing it within a single repository. It looks like rhodecode is calculating the common ancestor revision differently in these two cases.
Here is a minimal history that I can reproduce this with:
* a3da0b0 (longfeaturemerge) Merge branch 'main' into longfeaturemerge
|\
| * b91f196 (main) main
* | 462cb48 (HEAD -> longfeature) feature
* | b2f8010 Merge branch 'main' into longfeature
|\|
| * 850c812 main
* | fcaf39a feature
|/
* 58d6ae3 main
I load this history into a repo, and then fork it to an identical copy, repo-fork.
Creating a pull request from repo/longfeaturemerge to repo/longfeature uses a common ancestor of 462cb48f8196.
Creating a pull request from repo-fork/longfeaturemerge to repo/longfeature uses a common ancestor of 850c812a252e.
Both of these pull requests identify the same set of commits (b91f196adc0e, a3da0b0cbaf1). However, because of the change in common ancestor, they generate very different diff sets. Personally, I feel that the common ancestor of 462cb48f8196 is the ‘right’ selection, producing the more intuitive diff.
In reality, this came up when I wanted someone to review a messy merge resolution. With a lot of repo history the different ancestors was a difference of a million-line diff and a hundred-line diff, so it was a very meaningful difference.
I don’t mind looking into this more, but would love to know if this is actually expected behavior or a known issue already. I can also provide the test repo if that would make things more clear.
Reproduced in Rhodecode 5.5.1