[Bug] Merged PRs have their commits and files changed metadata 'zeroed'... sometimes.

[jamesorlakin]

• Gitea version (or commit ref): v1.11.3
• Git version: 2.24.1
• Operating system: Ubuntu 18.04 (used as a Docker host for Gitea)
• Database (use [x]):
  • PostgreSQL
  • MySQL
  • MSSQL
  • SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL)
  • No
  • Not relevant
• Log gist: N/A

Description

As of recent (within the last month I'd estimate), many PRs have their commits and files changed counters zeroed out after merging. This happens most of the time but weirdly not always on my instance now. Deleting the branch afterwards doesn't make seem to make a difference if that makes a difference.

I'm not sure how a lot of the internal Git plumbing works for Gitea so I haven't managed to take a look at the code directly. I know that #10618 seemed to be somewhat relevant - and the linked PR example in there does indeed show the behaviour below! I'm confused as to why this is shown for me as both branches definitely still exist.

Screenshots

[lunny]

It should be related with #10618. @zeripath

[zeripath]

Nope. Merged PRs are displayed by a different set of code.

gitea/routers/repo/pull.go

Lines 303 to 328 in 7225453

	// PrepareMergedViewPullInfo show meta information for a merged pull request view page
	func PrepareMergedViewPullInfo(ctx *context.Context, issue *models.Issue) *git.CompareInfo {
	pull := issue.PullRequest
	setMergeTarget(ctx, pull)
	ctx.Data["HasMerged"] = true
	compareInfo, err := ctx.Repo.GitRepo.GetCompareInfo(ctx.Repo.Repository.RepoPath(),
	pull.MergeBase, pull.GetGitRefName())
	if err != nil {
	if strings.Contains(err.Error(), "fatal: Not a valid object name") {
	ctx.Data["IsPullRequestBroken"] = true
	ctx.Data["BaseTarget"] = pull.BaseBranch
	ctx.Data["NumCommits"] = 0
	ctx.Data["NumFiles"] = 0
	return nil
	}
	ctx.ServerError("GetCompareInfo", err)
	return nil
	}
	ctx.Data["NumCommits"] = compareInfo.Commits.Len()
	ctx.Data["NumFiles"] = compareInfo.NumFiles
	return compareInfo
	}

[zeripath]

So the problem seems to be that the mergebase is incorrect - it's somehow ending up being the head!

[zeripath]

This means that v128.go is incorrect.

The trouble is that:

pr.MergeBase, err = git.NewCommand("merge-base", "--", pr.MergedCommitID+"^", gitRefName).RunInDir(repoPath)

Appears to have selected the gitRefName if it's a parent of MergedCommitID instead of searching for the common root for the other parent.

[jamesorlakin]

Would you reckon this is a migration problem? This has been happening on new PRs straight after merging.

I tried running it in debug mode (to use breakpoints) with SQLite in VS Code on my Windows machine but hit issues around needing gcc setup properly. I may try and migrate the existing DB to MySQL before investigating further if I get time tomorrow 😃

[zeripath]

It's probably the same issue if something recalculates the mergebase.

[zeripath]

We need to calculate the merge base from the other parents of the mergecommitid (if there are multiple parents)

git rev-list --parents -n 1 MERGE_COMMIT_ID

Will give the commit id followed by the parents. Can get the merge base from those.

Damn sorry for this bug the original code seemed to work in testing not sure why it didn't work in practice.

[jamesorlakin]

EDIT: Ignore me. It was the debugger... Printing it out to the console was fine.

[jamesorlakin]

Aah I think I've gotcha, so this bug will appear if the merge commit created by a PR has a parent that's also a merge commit? That would explain it not always appearing!

[zeripath]

@jamesorlakin - ah I see how you're getting the problem of the randomly updating merge base.

We're back to the race between the checker and merger - which is mostly fixed in 1.12

--

Nope that can't happen because we check if it is an ancestor...

[zeripath]

Are you sure you're definitely getting this after merging PRs? Could you check what the contenst of the version table is in your DB?

[jamesorlakin]

This instance (v1.11.3) is currently on DB version 118:

The MergeBase of the Pull model ends up being the commit that gitRefName points to:

It's very strange, and doesn't happen all the time. Some PRs are just fine after merging. I can't seem to figure out any consistent behaviour that would cause this - my theory about merge commits doesn't hold out, as we use a protected branch workflow so every commit the branch points to is a merge commit from a previous PR...