This is a very common git process, and it is exactly what gitlab and github do when you review a PR.
Instead of viewing the diff between two commits, they compare what changes have happened on the branch, and also omit changes that were just merges of the parent branch into the divergent branch.
In simple terms, If I create branchA off of master and then change 10 files, and then merge master into branchA that contains 100 changed files, and then I submit a PR in gitlab, then gitlab will only show the 10 changes and not the 100 changed files that were merged from the ancestor.
I believe git has this exact functionality built it. The syntax is using '...' in between the commit/branch names when diffing instead of using '..' syntax.
# This compares the tip of master to the tip of feature-login
git diff master..feature-login
# This compares the common ancestor to the tip of feature-login
git diff master...feature-login
It looks like Fork is doing the first one when comparing a branch, when it should be doing the second one IMO. When clicking on two branches in the sidebar, if it did the second option, Fork would not lose any behaviour because click on two commits does the same thing currently anyways.
This is a very common git process, and it is exactly what gitlab and github do when you review a PR.
Instead of viewing the diff between two commits, they compare what changes have happened on the branch, and also omit changes that were just merges of the parent branch into the divergent branch.
In simple terms, If I create branchA off of master and then change 10 files, and then merge master into branchA that contains 100 changed files, and then I submit a PR in gitlab, then gitlab will only show the 10 changes and not the 100 changed files that were merged from the ancestor.
I believe git has this exact functionality built it. The syntax is using '...' in between the commit/branch names when diffing instead of using '..' syntax.
It looks like Fork is doing the first one when comparing a branch, when it should be doing the second one IMO. When clicking on two branches in the sidebar, if it did the second option, Fork would not lose any behaviour because click on two commits does the same thing currently anyways.