The /compare/x...y page now displays diff from the merge-base to y instead of from x to y

[CyberShadow]

To reproduce:

$ git init repo && cd repo
Initialized empty Git repository in /home/vladimir/tmp/2020-07-28/repo/.git/

$ echo a > file.txt

$ git add . && git commit -m 'Initial commit'
[master (root-commit) 4b97f6e] Initial commit
 1 file changed, 1 insertion(+)
 create mode 100644 file.txt

$ echo b > file.txt

$ git commit -am 'b'
[master a9e140c] b
 1 file changed, 1 insertion(+), 1 deletion(-)

$ git checkout -b c 'HEAD^'
Switched to a new branch 'c'

$ echo c > file.txt

$ git commit -am 'c'
[c 80241e1] c
 1 file changed, 1 insertion(+), 1 deletion(-)

$ git push gitea master c
[...]

$ xdg-open https://..../compare/$(git rev-parse master)...$(git rev-parse c)

Visiting the compare URL with the SHA-1s of the two diverging branches shows the diff from their common ancestor to c, instead of from master to c.

This is a regression: this feature worked in 1.8.3 and stopped working in 1.9.6. It was extremely useful for viewing the diff from before and after a force-push.

I noticed that the URL syntax has three periods, and the new behavior thus matches git-diff's behavior when also using x...y (three periods - "symmetric difference"). Perhaps Gitea should support /compare/x..y (two periods) to do the same as the old behavior (direct diff from x to y)?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. I am here to help clear issues left open even if solved or waiting for more insight. This issue will be closed if no further activity occurs during the next 2 weeks. If the issue is still valid just add a comment to keep it alive. Thank you for your contributions.

[CyberShadow]

I believe this is still relevant.

[6543]

@CyberShadow witch gitea version do you use?

[CyberShadow]

We are on 1.8.3 for the time being due to this issue.

[6543]

@CyberShadow your version is not supported anymore :/

there is a good chance this bug is fixed in master ... didn't test current stable release nor master jet (give me some time)

In any case It's a good choice to upgrade to 1.12.4

[6543]

@CyberShadow fixed on master (upcomming v1.13.0): https://gitea.com/6543/test_12349/compare/ad9e3b6de19a388e42483ba062d0caadb843164e...b93dc2ee9e31660708f634c58ebbdc381b9ef8f6

and v1.12.x too: https://codeberg.org/6543/test_12349/compare/ad9e3b6de19a388e42483ba062d0caadb843164e...b93dc2ee9e31660708f634c58ebbdc381b9ef8f6

[6543]

@CyberShadow if you have questions about upgrade feel free to ask, I'll close this issue since this wont be fixed ...

[zeripath]

I'm gonna reopen it as I think we could support this.

[CyberShadow]

@6543 No, that's the wrong result. It needs to go from b (the ref in the URL) to c, not from a (the common ancestor) to c.

Kindly reopen.

[6543]

sorry then 🙃

and thanks for checking&reporting

[CyberShadow]

Worth mentioning is that GitHub follows Git's syntax convention in its URLs:

https://www.github.com/CyberShadow/gitea12349/compare/master..c <- two dots - direct compare from master to c
https://www.github.com/CyberShadow/gitea12349/compare/master...c <- three dots - compare merge-base of the two refs to c

Gitea could follow the same convention by adding the two-dot URL variant (or rather, restoring the pre-1.9 behavior with that URL syntax).

[wxiaoguang]

It should have been done in the latest release.

[CyberShadow]

Indeed, seems to work.

https://gitea.com/CyberShadow/test12349/compare/master..c
https://gitea.com/CyberShadow/test12349/compare/master...c

Thank you!