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

Created on 28 Jul 2020  路  11Comments  路  Source: go-gitea/gitea

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)?

kinbug

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).

All 11 comments

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 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).

Was this page helpful?
0 / 5 - 0 ratings