Improve the test for mergeability

[MarkusAmshove]

• 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: MarkusAmshove/Conflict#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.

[MarkusAmshove]

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 😆

[ollien]

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

[MarkusAmshove]

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