Improve the test for mergeability #3098

New Issue

GiteaMirror · 2025-11-02T05:00:42-06:00

GiteaMirror commented

2025-11-02 05:00:42 -06:00

Originally created by @markusamshove on GitHub (Mar 23, 2019).

Gitea version (or commit ref): cd8cdbd
Can you reproduce the bug at https://try.gitea.io:
https://try.gitea.io/conflicttest/noconflict/pulls/1

Description

In our workflow we have two branches with continuous deployment: master and qa (production and quality assurance).

Because both deploy on new pushes, they're both branch protected and require a PR with a review.

We always branch off new features from master and the first target after development is qa for acceptance testing.
We often seem to have conflicts when targeting a feature to qa, because the qa has more features that are currently in testing and are not released into master yet.
What we do then is manually resolve the issues so that git is able to merge it locally.
Merging qa into the feature is no option, because then the feature is dependent on other features that might not be ready for production.

Now to the Gitea part :-)

Have a look at this PR which emulates a conflict that is shown in Gitea but can be merged locally.
Gitea isn't able to merge it and just says it is conflicted.

However, you can do the following:

git clone https://try.gitea.io/conflicttest/noconflict
cd noconflict
git checkout qs
git merge --no-ff feature

Git is happy to merge it.

I've also tested what Github would show, here is the result: https://github.com/MarkusAmshove/Conflict/pull/1

The problem seems to be that Gitea "just" tries to apply the branch as a patch with, which can be reproduced locally:

[10:29] markus@suse-markus ~/scm/conflicttest (qs|✔) $ git format-patch feature --stdout | git apply --check --cached
error: Anwendung des Patches fehlgeschlagen: B:3
error: B: Patch konnte nicht angewendet werden

So, what could Gitea do better in that regard?

I think that instead of doing the patch approach, Gitea should try the different merge strategies it supports (which can be configured at the repositoy settings page) and see if the PR is actually mergeable.

We only have --no-ff enabled as a possibility and the exit code would be an indicator:

[10:39] markus@suse-markus ~/scm/conflicttest (qs|✔) $ git merge feature --no-ff --no-edit
Merge made by the 'recursive' strategy.
[10:39] markus@suse-markus ~/scm/conflicttest (qs↑ 3|✔) $ echo $status
0

In another repository where there are indeed conflicts:

[10:40] markus@suse-markus ~/scm/conflict (qa|✔) $ git merge feature2 --no-ff --no-edit
automatischer Merge von README.md
KONFLIKT (Inhalt): Merge-Konflikt in README.md
Automatischer Merge fehlgeschlagen; beheben Sie die Konflikte und committen Sie dann das Ergebnis.
[10:40] markus@suse-markus ~/scm/conflict (qa|MERGING|✖1⚡1) $ echo $status
1

Proposal

When testing for mergeability of a PR, try the different merge strategies configured in Gitea (for the repository) to see if the PR can be merged.

Bonus points if, when there are multiple strategies configured, Gitea "grays out" strategies that aren't possible.

Originally created by @markusamshove on GitHub (Mar 23, 2019). - Gitea version (or commit ref): `cd8cdbd` - Can you reproduce the bug at https://try.gitea.io: https://try.gitea.io/conflicttest/noconflict/pulls/1 ## Description In our workflow we have two branches with continuous deployment: `master` and `qa` (production and quality assurance). Because both deploy on new pushes, they're both branch protected and require a PR with a review. We always branch off new features from `master` and the first target after development is `qa` for acceptance testing. We often seem to have conflicts when targeting a feature to `qa`, because the `qa` has more features that are currently in testing and are not released into `master` yet. What we do then is manually resolve the issues so that git is able to merge it locally. Merging `qa` into the feature is no option, because then the feature is dependent on other features that might not be ready for production. Now to the Gitea part :-) Have a look at this [PR](https://try.gitea.io/conflicttest/noconflict/pulls/1) which emulates a conflict that is shown in Gitea but can be merged locally. Gitea isn't able to merge it and just says it is conflicted. However, you can do the following: ``` git clone https://try.gitea.io/conflicttest/noconflict cd noconflict git checkout qs git merge --no-ff feature ``` Git is happy to merge it. I've also tested what Github would show, here is the result: https://github.com/MarkusAmshove/Conflict/pull/1 The problem seems to be that Gitea "just" tries to apply the branch as a patch with, which can be reproduced locally: ``` [10:29] markus@suse-markus ~/scm/conflicttest (qs|✔) $ git format-patch feature --stdout | git apply --check --cached error: Anwendung des Patches fehlgeschlagen: B:3 error: B: Patch konnte nicht angewendet werden ``` So, what could Gitea do better in that regard? I think that instead of doing the patch approach, Gitea should try the different merge strategies it supports (which can be configured at the repositoy settings page) and see if the PR is actually mergeable. We only have `--no-ff` enabled as a possibility and the exit code would be an indicator: ``` [10:39] markus@suse-markus ~/scm/conflicttest (qs|✔) $ git merge feature --no-ff --no-edit Merge made by the 'recursive' strategy. [10:39] markus@suse-markus ~/scm/conflicttest (qs↑ 3|✔) $ echo $status 0 ``` In another repository where there are indeed conflicts: ``` [10:40] markus@suse-markus ~/scm/conflict (qa|✔) $ git merge feature2 --no-ff --no-edit automatischer Merge von README.md KONFLIKT (Inhalt): Merge-Konflikt in README.md Automatischer Merge fehlgeschlagen; beheben Sie die Konflikte und committen Sie dann das Ergebnis. [10:40] markus@suse-markus ~/scm/conflict (qa|MERGING|✖1⚡1) $ echo $status 1 ``` ## Proposal When testing for mergeability of a PR, try the different merge strategies configured in Gitea (for the repository) to see if the PR can be merged. Bonus points if, when there are multiple strategies configured, Gitea "grays out" strategies that aren't possible.

GiteaMirror added the type/proposal type/enhancement labels 2025-11-02 05:00:42 -06:00

GiteaMirror closed this issue

2025-11-02 05:00:42 -06:00

GiteaMirror commented

2025-11-02 05:00:43 -06:00

@markusamshove commented on GitHub (Mar 23, 2019):

Please note that this is a constructed example to show the limitations of the current check.

Having the same contents also results in Gitea showing 404 on the files tab:
https://try.gitea.io/conflicttest/conflict/pulls/1/files

While Github still shows the changes:
https://github.com/MarkusAmshove/Conflict/pull/1/files

I haven't investigated what Github could do different for the file diffs.

Edit: Don't mind the 404, I linked the wrong repository 😆

@markusamshove commented on GitHub (Mar 23, 2019): Please note that this is a constructed example to show the limitations of the current check. Having the same contents also results in Gitea showing 404 on the files tab: https://try.gitea.io/conflicttest/conflict/pulls/1/files While Github still shows the changes: https://github.com/MarkusAmshove/Conflict/pull/1/files I haven't investigated what Github could do different for the file diffs. Edit: Don't mind the 404, I linked the wrong repository 😆

GiteaMirror commented

2025-11-02 05:00:43 -06:00

@ollien commented on GitHub (Mar 24, 2019):

Did you mean to post https://try.gitea.io/conflicttest/noconflict/pulls/1? Your other links 404

@ollien commented on GitHub (Mar 24, 2019): Did you mean to post https://try.gitea.io/conflicttest/noconflict/pulls/1? Your other links 404

GiteaMirror commented

2025-11-02 05:00:43 -06:00

@markusamshove commented on GitHub (Mar 24, 2019):

You're right, I messed up the repository names :-)
I'll update the issue

@markusamshove commented on GitHub (Mar 24, 2019): You're right, I messed up the repository names :-) I'll update the issue

GiteaMirror referenced this issue

2025-11-02 12:18:42 -06:00