Branches with same content does not show empty diff #8934

New Issue

2025-11-02T08:23:32-06:00

GiteaMirror commented

2025-11-02 08:23:32 -06:00

Originally created by @jedi7 on GitHub (May 10, 2022).

Description

When user creates same content in separate branches. Then the diff shows differences even if the tree content is the same.

See repo https://try.gitea.io/jedi7/test_paralel_branches/src/branch/paralel

Also please see the screenshots

Gitea Version

1.16.7

Can you reproduce the bug on the Gitea demo site?

Yes

Log Gist

No response

Screenshots

Master branch with "test" content

Paralel branch with "test" content (added in different commit, so conflicting with master)

Invalid diff

Invalid PR

Git Version

web

Operating System

Archlinux

How are you running Gitea?

https://try.gitea.io/
also reproducible on released gitea 1.16.7

Database

SQLite

Originally created by @jedi7 on GitHub (May 10, 2022). ### Description When user creates same content in separate branches. Then the diff shows differences even if the tree content is the same. See repo https://try.gitea.io/jedi7/test_paralel_branches/src/branch/paralel Also please see the screenshots ### Gitea Version 1.16.7 ### Can you reproduce the bug on the Gitea demo site? Yes ### Log Gist _No response_ ### Screenshots Master branch with "test" content ![image](https://user-images.githubusercontent.com/24191306/167545261-dc9091da-ecd3-47cd-a17f-4fc8073c1bfe.png) Paralel branch with "test" content (added in different commit, so conflicting with master) ![image](https://user-images.githubusercontent.com/24191306/167545346-1604103a-8b62-45c6-b30f-43858dd6c38e.png) Invalid diff ![image](https://user-images.githubusercontent.com/24191306/167545460-33ad2a64-8a08-44f7-bead-1c17c100220e.png) Invalid PR ![image](https://user-images.githubusercontent.com/24191306/167545563-98ff19e7-91ee-4d59-aaf7-00af92e5d72f.png) ### Git Version web ### Operating System Archlinux ### How are you running Gitea? https://try.gitea.io/ also reproducible on released gitea 1.16.7 ### Database SQLite

GiteaMirror added the type/bug label 2025-11-02 08:23:32 -06:00

GiteaMirror commented

2025-11-02 08:23:32 -06:00

@Gusted commented on GitHub (May 11, 2022):

Then the diff shows differences even if the tree content is the same.

The diff is generated based of the older base branch commit. This diff seems to be as intended.

@Gusted commented on GitHub (May 11, 2022): > Then the diff shows differences even if the tree content is the same. The diff is generated based of the older base branch commit. This diff seems to be as intended.

GiteaMirror commented

2025-11-02 08:23:33 -06:00

@jedi7 commented on GitHub (May 11, 2022):

The diff is generated based of the older base branch commit. This diff seems to be as intended.

But why it should be intended? When comparing two branches, then user is interested in actual state (not what was before X commits).

@jedi7 commented on GitHub (May 11, 2022): > The diff is generated based of the older base branch commit. This diff seems to be as intended. But why it should be intended? When comparing two branches, then user is interested in actual state (not what was before X commits).

GiteaMirror commented

2025-11-02 08:23:33 -06:00

@Gusted commented on GitHub (May 11, 2022):

When comparing two branches, then user is interested in actual state (not what was before X commits).

In such case they should update the branch to include the latest change from the base branch. I'm pretty sure this is the same behavior for GitHub+GitLab.

@Gusted commented on GitHub (May 11, 2022): > When comparing two branches, then user is interested in actual state (not what was before X commits). In such case they should update the branch to include the latest change from the base branch. I'm pretty sure this is the same behavior for GitHub+GitLab.

GiteaMirror commented

2025-11-02 08:23:33 -06:00

@jedi7 commented on GitHub (May 11, 2022):

@Gusted true, github have the same behavior (just tested on the testing repo)
But still not understand how it is useful.
when comparing "master" and "paralel" branches.

master content: "test"
paralel content: "test"
github/gitea diff is "test"

but diff should be "" or at least say the content "test" is conflicting.
when I do git diff master paralel , then diff is empty.

Attaching test repo.
test-empty-merge-commit-paralel.tar.gz

@jedi7 commented on GitHub (May 11, 2022): @Gusted true, github have the same behavior (just tested on the testing repo) But still not understand how it is useful. when comparing "master" and "paralel" branches. master content: "test" paralel content: "test" github/gitea diff is "test" but diff should be "" or at least say the content "test" is conflicting. when I do `git diff master paralel` , then diff is empty. Attaching test repo. [test-empty-merge-commit-paralel.tar.gz](https://github.com/go-gitea/gitea/files/8667138/test-empty-merge-commit-paralel.tar.gz)

GiteaMirror commented

2025-11-02 08:23:33 -06:00

@Gusted commented on GitHub (May 11, 2022):

when I do git diff master paralel , then diff is empty.

Gitea doesn't use that diff, under-the-hood Gitea requests the merge-base of the paralel with master branch: https://github.com/go-gitea/gitea/blob/main/modules/git/repo_compare.go#L35 and that's the actual commit being used to diff against. In your case the command would return df1d83b5339dfe1155a12e0cc86085e3432addf1 which is the initial commit.

As of why we do this? I'm not entirely sure, but I assume if we would diff against the branch directly, any kind of conflict between the branches would lead to a inaccurate presentation of the diff.

@Gusted commented on GitHub (May 11, 2022): > when I do `git diff master paralel` , then diff is empty. Gitea doesn't use that diff, under-the-hood Gitea requests [the merge-base](https://git-scm.com/docs/git-merge-base) of the `paralel` with `master` branch: https://github.com/go-gitea/gitea/blob/main/modules/git/repo_compare.go#L35 and that's the actual commit being used to diff against. In your case the command would return `df1d83b5339dfe1155a12e0cc86085e3432addf1` which is the initial commit. As of why we do this? I'm not entirely sure, but I assume if we would diff against the branch directly, any kind of conflict between the branches would lead to a inaccurate presentation of the diff.

GiteaMirror commented

2025-11-02 08:23:33 -06:00

@jedi7 commented on GitHub (May 11, 2022):

Thank you for explanation of the mechanics in gitea, I think I understand now.
Question is, if this behavior is ok, or is there space for improve.

From my point of view will be useful this behavior:

diff actual branches and mark what was added, removed and (newly) what is conflicting.

Actual behavior is for me little misleading, because for example I can think I'm fixing a bug, but somebody else did it already and I will not see it in diff.

@jedi7 commented on GitHub (May 11, 2022): Thank you for explanation of the mechanics in gitea, I think I understand now. Question is, if this behavior is ok, or is there space for improve. From my point of view will be useful this behavior: * diff actual branches and mark what was added, removed and (newly) what is conflicting. Actual behavior is for me little misleading, because for example I can think I'm fixing a bug, but somebody else did it already and I will not see it in diff.

GiteaMirror commented

2025-11-02 08:23:34 -06:00

@Gusted commented on GitHub (May 12, 2022):

Question is, if this behavior is ok, or is there space for improve.

I'm not sure if there's space to improve, if it was possible to diff against the branch's HEAD by-default the reverse could happen, code added into the base-branch would now show up as "added" or "removed" in the PR's diff(which we avoid by using the merge-base). To actually have such feature/option we would to merge the branch to not be out-of-date and then do the diff against the branch's HEAD but is a bit misleading and the performance would be degraded especially for very out-of-date PR's where to merge the base branch can take some time.

Actual behavior is for me little misleading, because for example I can think I'm fixing a bug, but somebody else did it already and I will not see it in diff.

Well, Gitea already marks PR's as out-of-date and it's common practice to first merge the latest commit(s) of the base's branch into the PR to avoid such things. But to improve Gitea in such cases, to e.g. show a message if such thing has happpend shouldn't be accomplished by changing how the diff mechanism works, it has no direct benefit and doesn't actually show that it has happen(unless the author has good memory and notices that certain code is missing in the diff).

@Gusted commented on GitHub (May 12, 2022): > Question is, if this behavior is ok, or is there space for improve. I'm not sure if there's space to improve, if it was possible to diff against the branch's HEAD by-default the reverse could happen, code added into the base-branch would now show up as "added" or "removed" in the PR's diff(which we avoid by using the merge-base). To actually have such feature/option we would to merge the branch to not be out-of-date and then do the diff against the branch's HEAD but is a _bit misleading_ and the performance would be degraded especially for very out-of-date PR's where to merge the base branch can take some time. > Actual behavior is for me little misleading, because for example I can think I'm fixing a bug, but somebody else did it already and I will not see it in diff. Well, Gitea already marks PR's as out-of-date and it's common practice to first merge the latest commit(s) of the base's branch into the PR to avoid such things. But to improve Gitea in such cases, to e.g. show a message if such thing has happpend shouldn't be accomplished by changing how the diff mechanism works, it has no direct benefit and doesn't actually show that it has happen(unless the author has good memory and notices that certain code is missing in the diff).

GiteaMirror commented

2025-11-02 08:23:34 -06:00

@hramrach commented on GitHub (Nov 1, 2023):

It's common but not universal practice to only merge up-to-date branches.

The gitea UI clearly does not support the other option - merging branches that are not up-to-date.

Some forges provide a 'rebase' button that does automated rebase.

Many forges also show if the branch can be merged or if it conflicts in the PR status, and that's a useful feature to have.

To calculate if there is a conflict the merge needs to be done, and then diff of the merge against the branch head can be shown as well.

@hramrach commented on GitHub (Nov 1, 2023): It's common but not universal practice to only merge up-to-date branches. The gitea UI clearly does not support the other option - merging branches that are not up-to-date. Some forges provide a 'rebase' button that does automated rebase. Many forges also show if the branch can be merged or if it conflicts in the PR status, and that's a useful feature to have. To calculate if there is a conflict the merge needs to be done, and then diff of the merge against the branch head can be shown as well.

GiteaMirror commented

2025-11-02 08:23:34 -06:00

@Eddcapone commented on GitHub (Nov 29, 2023):

I was confused too. It would be nice if the "Changed Files" Tab would only show the files, which actually changed.
I suggest that you provide atleast another diff option so that only the actual changed files are showing.

You could run a foreach on all files and execute a git diff target feature $filename and if the output is empty, then simply don't show the file.

@Eddcapone commented on GitHub (Nov 29, 2023): I was confused too. It would be nice if the "Changed Files" Tab would only show the files, which actually changed. I suggest that you provide atleast another diff option so that only the actual changed files are showing. You could run a foreach on all files and execute a `git diff target feature $filename` and if the output is empty, then simply don't show the file.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#8934