Conflicting files shown on pull request but merging without conflict

[mschoettle]

• Gitea version (or commit ref): 1.12.5 and 1.14.0+dev-251-g78204a7a7
• Git version: 2.24.1
• Operating system:
• Database (use [x]):
  • PostgreSQL
  • MySQL
  • MSSQL
  • SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL)
  • No
• Log gist:

Description

I created a pull request which showed me that one of the files was conflicting. I then wanted to resolve this conflict locally but the merge worked just fine.

I re-created this on try.gitea.io with a simplified example, see this test repo: https://try.gitea.io/test-gitea3/conflict-test

Steps taken:

1. created initial version on master
2. created branch test
3. modified same file on branch test
4. modified same file on branch master
5. created PR

Result:

This pull request has changes conflicting with the target branch.
settings.py

This is the output when merging locally:

$ git merge test
Auto-merging settings.py
Merge made by the 'recursive' strategy.
 settings.py | 41 +++++++++++++++++++++++++++++++++++++++--
 1 file changed, 39 insertions(+), 2 deletions(-)

[6543]

the easyest workarounds would either be a rebase or a merge from base int head-branch localy and push result

[lunny]

I found sometimes github also have the problem. It seems it depends on different merge style.

[mschoettle]

Interesting. How are the conflicting files determined?

[a1012112796]

check logic is here
note: tracking is the head branch

gitea/services/pull/patch.go

Lines 111 to 126 in 24330f7

	if err := gitRepo.GetDiff(pr.MergeBase, "tracking", tmpPatchFile); err != nil {
	tmpPatchFile.Close()
	log.Error("Unable to get patch file from %s to %s in %s Error: %v", pr.MergeBase, pr.HeadBranch, pr.BaseRepo.FullName(), err)
	return false, fmt.Errorf("Unable to get patch file from %s to %s in %s Error: %v", pr.MergeBase, pr.HeadBranch, pr.BaseRepo.FullName(), err)
	}
	stat, err := tmpPatchFile.Stat()
	if err != nil {
	tmpPatchFile.Close()
	return false, fmt.Errorf("Unable to stat patch file: %v", err)
	}
	patchPath := tmpPatchFile.Name()
	tmpPatchFile.Close()
	// 1a. if the size of that patch is 0 - there can be no conflicts!
	if stat.Size() == 0 {

[a1012112796]

maybe we can try this way

# try merge by ``--no-commit``
zzc:conflict-test (master)$ git merge --no-commit --no-ff test_2 
Auto-merging aa.c
CONFLICT (content): Merge conflict in aa.c
Automatic merge failed; fix conflicts and then commit the result.
# get conflict markers by ``--check``
zzc:conflict-test (master *+|MERGING)$ git diff --check 
aa.c:3: leftover conflict marker
aa.c:5: leftover conflict marker
aa.c:7: leftover conflict marker
zzc:conflict-test (master *+|MERGING)$ 

[zeripath]

$ git merge test
Auto-merging settings.py
Merge made by the 'recursive' strategy.
 settings.py | 41 +++++++++++++++++++++++++++++++++++++++--
 1 file changed, 39 insertions(+), 2 deletions(-)

Please note the Merge made by 'recursive' strategy. That means that the merge required a checked out copy of the codebase to do the merge. We cannot do that.

@a1012112796 your proposal would also require a complete checked out copy of the codebase.

[a1012112796]

$ git merge test
Auto-merging settings.py
Merge made by the 'recursive' strategy.
 settings.py | 41 +++++++++++++++++++++++++++++++++++++++--
 1 file changed, 39 insertions(+), 2 deletions(-)

Please note the merge made by 'recursive' strategy. That means that the merge required a checked out copy of the codebase to do the merge. We cannot do that.

@a1012112796 your proposal would also require a complete checked out copy of the codebase.

@zacheryph secound choice, should check diff beturn head branch and merge base if they are not same. only when the file has been changed is in git diff merge_base head_branch and git diff merge_base base_branch is maybe real conflict file, need check it again by git merge-file. how about this way?

[MarkusAmshove]

Related: #6417

[stale]

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.

[zeripath]

I think we need to be clear here that the automatic system in gitea can never be as good a merger as git on the command line.

Why?

Well git on the command line has a checked out copy and can do octopus merges and take account of history to resolve conflicts that the system cannot do.

We can only do basic diff patch applications.

[lunny]

In fact, github also has the problem.