What fresh hell did you subject that poor little linter to now?

@TomJo2000 I have discovered this method (visible in this PR) of consistently triggering a bug in lint-packages.sh.

Important notes:

• It is not reproducible under normal conditions in local repository clones. The GitHub Actions CI codepath (or some sufficiently accurate simulation of it) is required to reproduce it

• It is very difficult to explain the steps that are necessary to reproduce it consistently to someone else, but I could try. The easiest way for me to show what is wrong is for me to create this PR, which demonstrates it.

• I am hoping to work with you and discuss this problem so that we can try to find a permanent solution to this bug

• I can write longer explanations like links to code blocks I believe are involved with a program, debugging and workaround patches I used in the process of learning how to consistently reproduce this and temporarily work around it, and more, but first, I wanted to ask,

  • When you look at this error, what is your first impression of what you think might be causing this, and do any ideas come to mind of what you might be able to do to fix this, or do you draw a blank on this at the moment until I try to explain more?

My first impression of the issue is that empty commits seem to be messing up the git rev-list --count.
But that doesn't make a ton of sense to me.

Will need more testing.

I think the obvious first step is making failures louder.
How many commits did it count, what is it using as the base commit, how did it come to the conclusion that there was a version bump in the range.

My first impression of the issue is that empty commits seem to be messing up the git rev-list --count. But that doesn't make a ton of sense to me.

I can let you know that if I changed some random thing somewhere that isn't linted, like README.md for example, in those 5 dummy commits, instead of making empty commits, then the problem would still reproduce. Manipulating the number of commits in the PR relative to some things is what reproduces it, not specifically the content of those dummy commits.

Will need more testing.

Ok sounds good, please ask me for clarification if you need more explanation about any other things

How many commits did it count, what is it using as the base commit, how did it come to the conclusion that there was a version bump in the range.

Yes, the problem has to do with that, that is on the right track, but it's hard to explain exactly how.

I'm going to show you one of the most useful debugging patches that I used to debug this to the point that I can consistently reproduce it. Wait a moment.

@TomJo2000 I've applied a form of the debugging print message patch that I used to learn how to consistently reproduce this. Please take a look at the log now, and in particular, pay close attention to the top of the git log command output. That log is particularly what caused me to begin to understand what is going wrong, when I first saw it.

Oh, the log of the command $(git rev-parse $base_commit) is also helpful, but I forgot to show that. Please let me know if you need to see that output too.

base_commit: HEAD~2
HEAD commit hash: c8309f354d98e0a7f60c916ba6a036fcc03167e4
git status: HEAD detached at pull/27168/merge
Untracked files:
  (use "git add <file>..." to include in what will be committed)
	built_termux-main_packages.txt
	built_termux-main_subpackages.txt

nothing added to commit but untracked files present (use "git add" to track)
git log: commit c8309f354d98e0a7f60c916ba6a036fcc03167e4
Merge: 9888d735 473f4beb
Author: Robert Kirkman <31490854+robertkirkman@users.noreply.github.com>
Date:   Sun Nov 9 06:59:57 2025 -0600

    Merge 473f4bebec9837cd3fe65214bd74f09919c28896 into 9888d73522d238518683bd4aca4c8920c294f264

commit 473f4bebec9837cd3fe65214bd74f09919c28896
Author: Robert Kirkman <rkirkman@termux.dev>
Date:   Sun Nov 9 06:59:47 2025 -0600

    temporary debugging print messages in `lint-packages.sh`

commit ec4850db06bb33b921826ae1c951e4665b603274
Author: Robert Kirkman <rkirkman@termux.dev>
Date:   Sun Nov 9 06:39:30 2025 -0600

    revbump(main/llama-cpp): 0.0.0-b6996-1
    
    - This PR will force `lint-packages.sh` to break

commit 19e9f186cbc471c3e9463044e95fdc250f49720c
Author: Robert Kirkman <rkirkman@termux.dev>
Date:   Sun Nov 9 06:39:03 2025 -0600

    force break `lint-packages.sh` dummy commit 5

commit bc2a7f04ea10ea0ea2d557cfd3461b89636501fe
Author: Robert Kirkman <rkirkman@termux.dev>
Date:   Sun Nov 9 06:39:02 2025 -0600

    force break `lint-packages.sh` dummy commit 4

commit a0925d5bb529d801d5bcd37c05ef797110e85d70
Author: Robert Kirkman <rkirkman@termux.dev>
Date:   Sun Nov 9 06:39:00 2025 -0600

    force break `lint-packages.sh` dummy commit 3

commit 7c684bec59c86e090fa076cfb8ab41dd219cffbb
Author: Robert Kirkman <rkirkman@termux.dev>
Date:   Sun Nov 9 06:38:59 2025 -0600

    force break `lint-packages.sh` dummy commit 2

commit 7a7d0339e4f169e6667bc44fc7e06be29b6c3b7b
Author: Robert Kirkman <rkirkman@termux.dev>
Date:   Sun Nov 9 06:38:53 2025 -0600

    force break `lint-packages.sh` dummy commit 1

commit 9888d73522d238518683bd4aca4c8920c294f264
Author: Termux Github Actions <contact@termux.dev>
Date:   Sun Nov 9 12:14:04 2025 +0000

    bump(main/llama-cpp): 0.0.0-b6996
    
    This commit has been automatically submitted by Github Actions.

commit 78518d906e9c907d38941b9f7348000b2b55de58
Author: Termux Github Actions <contact@termux.dev>
Date:   Sun Nov 9 06:15:34 2025 +0000

    bump(main/jackett): 0.24.268
    
    This commit has been automatically submitted by Github Actions.

HEAD~2 would then contain the bump to llama-cpp, so it gets picked up by git diff.
I don't know what if anything we can do about that other than cracking down on merge commits even harder.

I don't know what if anything we can do about that other than cracking down on merge commits even harder.

Good idea, but go ahead and check something - where is the merge commit in this PR?

Can you find where it is? I can help point it out if necessary.

According to git log it's c8309f3 which isn't on that list...

Could you try adding --no-merges to the git rev-list command(s)?

And I guess also to the git diff?
I'm actually not convinced it's gonna do anything on rev-list... But it seems like we should add --no-merges there as well.

• By the way should I pack these fixes into enhance(scripts/lint-packages.sh): optimize handling of version arrays #27095 or would you prefer a separate PR for that?

• By the way should I pack these fixes into enhance(scripts/lint-packages.sh): optimize handling of version arrays #27095 or would you prefer a separate PR for that?

It's up to you, but for organization purposes it might be best as a separate PR which can be marked as "fixing" this PR.

Could you try adding --no-merges to the git rev-list command(s)?

And I guess also to the git diff? I'm actually not convinced it's gonna do anything on rev-list... But it seems like we should add --no-merges there as well.

Sure I will try that

closing keywords can also be put on commits as trailers.
and I think I'd prefer grouping it into #27095 in this instance.

Could you try adding --no-merges to the git rev-list command(s)?

And I guess also to the git diff? I'm actually not convinced it's gonna do anything on rev-list... But it seems like we should add --no-merges there as well.

I think that works! I didn't know that would work. Thank you!

So that you fully understand, the merge commit comes from this line, I think:

I didn't know what to do to actually fix this, though. your idea seems like it works.

I don't get how that is even creating a merge commit.

• @twaik added this in ci(packages.yml): ban merge commits in PRs to avoid wasting CI time #24383 to catch merge commits with a warning.
  The code seems fine to me.

I don't get how that is even creating a merge commit.

* @twaik added this in [ci(packages.yml): ban merge commits in PRs to avoid wasting CI time #24383](https://github.com/termux/termux-packages/pull/24383) to catch merge commits with a warning.
  The code seems fine to me.

oh, I think you're right, well, I don't know what is creating the merge commit. but you can see that whatever it is doesn't get caught by that check, so the CI proceeds onward silently and messes up the current lint-packages.sh version, unless we either change lint-packages.sh with your suggestion, or find what is actually creating the merge commit, and change that instead.

Ohh ok it seems like, as far as I can tell, the code which is creating the merge commit is somewhere in this repository:

• https://github.com/actions/checkout

Because, this issue is discussing it, where others have had similar problems:

• Why a merge commit for pull requests? actions/checkout#504

and the README.md of https://github.com/actions/checkout has this section where it says that to turn off the merge commit, explicitly setting with: ref: ${{ github.event.pull_request.head.sha }} is required.

https://github.com/actions/checkout?tab=readme-ov-file#checkout-pull-request-head-commit-instead-of-merge-commit

This would mean that the area where the merge commit is actually happening from the side of https://github.com/termux/termux-packages is here:

and since that is before everything else in the CI, I assume that actually turning off the merge commit might break other things that have already been developed to account for it.

I'll leave that rabbit hole in your capable hands.
I pushed the commit to #27095 to add --no-merges where applicable.

ok, unfortunately, I thought so. For some reason, unfortunately this PR starting to pass the linter was a false positive, because when I run another (fresh) test applying my method of consistently reproducing the problem, the problem comes back, even with --no-merges applied.

• revbump(main/whois): 5.6.5-1 #27171