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)?
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.
I believe this is still relevant.
@CyberShadow witch gitea version do you use?
We are on 1.8.3 for the time being due to this issue.
@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
@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
@CyberShadow if you have questions about upgrade feel free to ask, I'll close this issue since this wont be fixed ...
I'm gonna reopen it as I think we could support this.
@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.
sorry then 馃檭
and thanks for checking&reporting
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).
Most helpful comment
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).