[Commits Bug]: pkgcheck should compare to merge-base rather than origin

[mgorny]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

Running pkgcheck scan --commits check all packages changed compared to origin. When you have an unrebased branch, this means reporting results for packages that have changed in origin rather than your changes, which are entirely irrelevant and clutter the output.

Expected Behavior

I think it would be better to compare against merge-base between origin and the current branch.

master commit id

n/a

HEAD link

n/a

pkgcheck version

pkgcheck 0.10.38-4-g35bc261 -- Fri, 1 Aug 2025 18:16:44 +0300

pkgcore version

pkgcore 0.12.31-5-ge9e19ac -- Sat, 23 Aug 2025 10:05:02 +0300

git remotes configuration

mgorny git@github.com:mgorny/gentoo (fetch)
mgorny git@github.com:mgorny/gentoo (push)
origin git@git.gentoo.org:repo/gentoo.git (fetch)
origin git@git.gentoo.org:repo/gentoo.git (push)

[negril]

FWIW I always run --commits $(git merge-base master HEAD)..HEAD or for guru --commits $(git merge-base origin/dev HEAD)..HEAD.

[ferringb]

Kind of a philosophical argument: pkgcheck usage isn't something like actual code development were you're working in isolation and eventually kicking it upstream. The results are only relevant to the 'real' state of the world, IE, origin. At least for gentoo ebuild repos, as far as I know they also block all merge bases and require commits to linearly stack.

My point there is the only results really relevant are against that scenario since it's the common one. I think. :)

What is your usage scenario where the tracking branch is advancing but you're not able to rebase the content forward? If this were an actual codebase I'd fully get it, but exempting eclasses, I'm not following the problem.

Specifically in looking at this ticket, I'm worried about the consequence for this change for the assumptions of the common usage scenario.

So... what's the workflow? Why would you run pkgcheck against something unrebased? What benefit are you after in this sort of isolation, vs the fact you'll have to do a pkgcheck post rebase anyways?

[mgorny]

The actual use case is not wasting resources in rebasing before checking for issues that may require further fixups and therefore another rebase afterwards.

[negril]

If you create a branch for a pull request and modify it at some later point you will need to use --commits $(git merge-base master HEAD)..HEAD or you check all commits pushed to master since branching.

This goes similarly for guru if you don't constantly rebase your commit against origin/dev.