Groups keyboard shortcuts have been updated
Dismiss
See shortcuts

NullPointerException while fetching Gerrit repository

250 views
Skip to first unread message

Rodion

unread,
Mar 20, 2025, 11:43:52 AMMar 20
to Repo and Gerrit Discussion
Hello, when I fetch Gerrit repository I get 'remote: error: internal error'. In gerrit logs I found the following errors: 
[ReceiveCommits-8[receive-commits]-for-SSH git-receive-pack /my/repository (user)] ERROR com.google.gerrit.server.git.receive.ReceiveCommits : ReceiveCommits failed due to NullPointerException java.lang.NullPointerException: change 123456: change not processed by merge strategy at java.base/java.util.Objects.requireNonNull(Objects.java:259) at com.google.gerrit.server.submit.SubmitStrategyListener.checkCommitStatus(SubmitStrategyListener.java:107) at com.google.gerrit.server.submit.SubmitStrategyListener.afterUpdateRepos(SubmitStrategyListener.java:57) at com.google.gerrit.server.update.BatchUpdates.notifyAfterUpdateRepo(BatchUpdates.java:155) at com.google.gerrit.server.update.BatchUpdates.execute(BatchUpdates.java:110) at com.google.gerrit.server.update.SubmissionExecutor.execute(SubmissionExecutor.java:66) at com.google.gerrit.server.submit.MergeOp.integrateIntoHistory(MergeOp.java:934) at com.google.gerrit.server.submit.MergeOp.lambda$merge$2(MergeOp.java:760) at com.google.gerrit.server.update.RetryableChangeAction.lambda$new$0(RetryableChangeAction.java:48) at com.google.gerrit.server.update.RetryableAction.lambda$new$0(RetryableAction.java:94) at com.github.rholder.retry.AttemptTimeLimiters$NoAttemptTimeLimit.call(AttemptTimeLimiters.java:78) at com.github.rholder.retry.Retryer.call(Retryer.java:160) at com.google.gerrit.server.update.RetryHelper.executeWithTimeoutCount(RetryHelper.java:598) at com.google.gerrit.server.update.RetryHelper.execute(RetryHelper.java:541) at com.google.gerrit.server.update.RetryableAction.call(RetryableAction.java:192) at com.google.gerrit.server.update.RetryableChangeAction.call(RetryableChangeAction.java:84) at com.google.gerrit.server.submit.MergeOp.merge(MergeOp.java:769) at com.google.gerrit.server.git.receive.ReceiveCommits.submit(ReceiveCommits.java:3144) at com.google.gerrit.server.git.receive.ReceiveCommits.insertChangesAndPatchSets(ReceiveCommits.java:1199) at com.google.gerrit.server.git.receive.ReceiveCommits.processCommandsUnsafe(ReceiveCommits.java:921) at com.google.gerrit.server.git.receive.ReceiveCommits.processCommands(ReceiveCommits.java:730) at com.google.gerrit.server.git.receive.AsyncReceiveCommits.lambda$preReceive$2(AsyncReceiveCommits.java:386) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317) at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:572) at com.google.gerrit.server.util.RequestScopePropagator.lambda$cleanup$1(RequestScopePropagator.java:187) at com.google.gerrit.server.util.RequestScopePropagator.lambda$context$0(RequestScopePropagator.java:174) at com.google.gerrit.server.util.ThreadLocalRequestScopePropagator.lambda$wrapImpl$0(ThreadLocalRequestScopePropagator.java:47) at com.google.gerrit.server.util.RequestScopePropagator$1.call(RequestScopePropagator.java:85) at com.google.gerrit.server.util.RequestScopePropagator$2.run(RequestScopePropagator.java:116) at com.google.gerrit.server.logging.LoggingContextAwareRunnable.run(LoggingContextAwareRunnable.java:113) at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:572) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317) at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) at com.google.gerrit.server.git.WorkQueue$Task.run(WorkQueue.java:912) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642) at java.base/java.lang.Thread.run(Thread.java:1583)

and 

[2025-03-18T09:44:15.794Z] [SSH git-receive-pack /my/repository (user)] ERROR com.google.gerrit.server.git.receive.AsyncReceiveCommits : error while processing push
java.util.concurrent.ExecutionException: java.lang.NullPointerException: change 68592: change not processed by merge strategy
        at java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122)
        at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:191)
        at com.google.gerrit.server.git.receive.AsyncReceiveCommits.preReceive(AsyncReceiveCommits.java:407)
        at com.google.gerrit.server.git.receive.AsyncReceiveCommits.lambda$asHook$0(AsyncReceiveCommits.java:351)
        at org.eclipse.jgit.transport.ReceivePack.service(ReceivePack.java:2287)
        at org.eclipse.jgit.transport.ReceivePack.receive(ReceivePack.java:2200)
        at com.google.gerrit.sshd.commands.Receive.runImpl(Receive.java:98)
        at com.google.gerrit.sshd.AbstractGitCommand.service(AbstractGitCommand.java:109)
        at com.google.gerrit.sshd.AbstractGitCommand$1.run(AbstractGitCommand.java:74)
        at com.google.gerrit.sshd.BaseCommand$TaskThunk.run(BaseCommand.java:492)
        at com.google.gerrit.server.logging.LoggingContextAwareRunnable.run(LoggingContextAwareRunnable.java:113)
        at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:572)
        at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317)
        at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
        at com.google.gerrit.server.git.WorkQueue$Task.run(WorkQueue.java:912)
        at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
        at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
        at java.base/java.lang.Thread.run(Thread.java:1583)
Caused by: java.lang.NullPointerException: change 68592: change not processed by merge strategy
        at java.base/java.util.Objects.requireNonNull(Objects.java:259)
        at com.google.gerrit.server.submit.SubmitStrategyListener.checkCommitStatus(SubmitStrategyListener.java:107)
        at com.google.gerrit.server.submit.SubmitStrategyListener.afterUpdateRepos(SubmitStrategyListener.java:57)
        at com.google.gerrit.server.update.BatchUpdates.notifyAfterUpdateRepo(BatchUpdates.java:155)
        at com.google.gerrit.server.update.BatchUpdates.execute(BatchUpdates.java:110)
        at com.google.gerrit.server.update.SubmissionExecutor.execute(SubmissionExecutor.java:66)
        at com.google.gerrit.server.submit.MergeOp.integrateIntoHistory(MergeOp.java:934)
        at com.google.gerrit.server.submit.MergeOp.lambda$merge$2(MergeOp.java:760)
        at com.google.gerrit.server.update.RetryableChangeAction.lambda$new$0(RetryableChangeAction.java:48)
        at com.google.gerrit.server.update.RetryableAction.lambda$new$0(RetryableAction.java:94)
        at com.github.rholder.retry.AttemptTimeLimiters$NoAttemptTimeLimit.call(AttemptTimeLimiters.java:78)
        at com.github.rholder.retry.Retryer.call(Retryer.java:160)
        at com.google.gerrit.server.update.RetryHelper.executeWithTimeoutCount(RetryHelper.java:598)
        at com.google.gerrit.server.update.RetryHelper.execute(RetryHelper.java:541)
        at com.google.gerrit.server.update.RetryableAction.call(RetryableAction.java:192)
        at com.google.gerrit.server.update.RetryableChangeAction.call(RetryableChangeAction.java:84)
        at com.google.gerrit.server.submit.MergeOp.merge(MergeOp.java:769)
        at com.google.gerrit.server.git.receive.ReceiveCommits.submit(ReceiveCommits.java:3144)
        at com.google.gerrit.server.git.receive.ReceiveCommits.insertChangesAndPatchSets(ReceiveCommits.java:1199)
        at com.google.gerrit.server.git.receive.ReceiveCommits.processCommandsUnsafe(ReceiveCommits.java:921)
        at com.google.gerrit.server.git.receive.ReceiveCommits.processCommands(ReceiveCommits.java:730)
        at com.google.gerrit.server.git.receive.AsyncReceiveCommits.lambda$preReceive$2(AsyncReceiveCommits.java:386)
        at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317)
        at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:572)
        at com.google.gerrit.server.util.RequestScopePropagator.lambda$cleanup$1(RequestScopePropagator.java:187)
        at com.google.gerrit.server.util.RequestScopePropagator.lambda$context$0(RequestScopePropagator.java:174)
        at com.google.gerrit.server.util.ThreadLocalRequestScopePropagator.lambda$wrapImpl$0(ThreadLocalRequestScopePropagator.java:47)
        at com.google.gerrit.server.util.RequestScopePropagator$1.call(RequestScopePropagator.java:85)
        at com.google.gerrit.server.util.RequestScopePropagator$2.run(RequestScopePropagator.java:116)
        ... 8 more

What can be the root of the problem? 

Matthias Sohn

unread,
Mar 20, 2025, 11:51:22 AMMar 20
to Rodion, Repo and Gerrit Discussion
On Thu, Mar 20, 2025 at 4:43 PM Rodion <rodvla...@gmail.com> wrote:
Hello, when I fetch Gerrit repository I get 'remote: error: internal error'. In gerrit logs I found the following errors: 
[ReceiveCommits-8[receive-commits]-for-SSH git-receive-pack /my/repository (user)] ERROR com.google.gerrit.server.git.receive.ReceiveCommits : ReceiveCommits failed due to NullPointerException java.lang.NullPointerException: change 123456: change not processed by merge strategy at java.base/java.util.Objects.requireNonNull(Objects.java:259) at com.google.gerrit.server.submit.SubmitStrategyListener.checkCommitStatus(SubmitStrategyListener.java:107) at com.google.gerrit.server.submit.SubmitStrategyListener.afterUpdateRepos(SubmitStrategyListener.java:57) at com.google.gerrit.server.update.BatchUpdates.notifyAfterUpdateRepo(BatchUpdates.java:155) at com.google.gerrit.server.update.BatchUpdates.execute(BatchUpdates.java:110) at com.google.gerrit.server.update.SubmissionExecutor.execute(SubmissionExecutor.java:66) at com.google.gerrit.server.submit.MergeOp.integrateIntoHistory(MergeOp.java:934) at com.google.gerrit.server.submit.MergeOp.lambda$merge$2(MergeOp.java:760) at com.google.gerrit.server.update.RetryableChangeAction.lambda$new$0(RetryableChangeAction.java:48) at com.google.gerrit.server.update.RetryableAction.lambda$new$0(RetryableAction.java:94) at com.github.rholder.retry.AttemptTimeLimiters$NoAttemptTimeLimit.call(AttemptTimeLimiters.java:78) at com.github.rholder.retry.Retryer.call(Retryer.java:160) at com.google.gerrit.server.update.RetryHelper.executeWithTimeoutCount(RetryHelper.java:598) at com.google.gerrit.server.update.RetryHelper.execute(RetryHelper.java:541) at com.google.gerrit.server.update.RetryableAction.call(RetryableAction.java:192) at com.google.gerrit.server.update.RetryableChangeAction.call(RetryableChangeAction.java:84) at com.google.gerrit.server.submit.MergeOp.merge(MergeOp.java:769) at com.google.gerrit.server.git.receive.ReceiveCommits.submit(ReceiveCommits.java:3144) at com.google.gerrit.server.git.receive.ReceiveCommits.insertChangesAndPatchSets(ReceiveCommits.java:1199) at com.google.gerrit.server.git.receive.ReceiveCommits.processCommandsUnsafe(ReceiveCommits.java:921) at com.google.gerrit.server.git.receive.ReceiveCommits.processCommands(ReceiveCommits.java:730) at com.google.gerrit.server.git.receive.AsyncReceiveCommits.lambda$preReceive$2(AsyncReceiveCommits.java:386) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317) at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:572) at com.google.gerrit.server.util.RequestScopePropagator.lambda$cleanup$1(RequestScopePropagator.java:187) at com.google.gerrit.server.util.RequestScopePropagator.lambda$context$0(RequestScopePropagator.java:174) at com.google.gerrit.server.util.ThreadLocalRequestScopePropagator.lambda$wrapImpl$0(ThreadLocalRequestScopePropagator.java:47) at com.google.gerrit.server.util.RequestScopePropagator$1.call(RequestScopePropagator.java:85) at com.google.gerrit.server.util.RequestScopePropagator$2.run(RequestScopePropagator.java:116) at com.google.gerrit.server.logging.LoggingContextAwareRunnable.run(LoggingContextAwareRunnable.java:113) at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:572) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317) at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) at com.google.gerrit.server.git.WorkQueue$Task.run(WorkQueue.java:912) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642) at java.base/java.lang.Thread.run(Thread.java:1583)

 
please reformat this stacktrace, it's not well formatted
Which Gerrit version do you use ?

-Matthias
 

--
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/repo-discuss/440a0a5b-90e7-40d9-8efe-9bef962a4d1bn%40googlegroups.com.

Luca Milanesio

unread,
Mar 20, 2025, 4:03:54 PMMar 20
to Repo and Gerrit Discussion, Luca Milanesio


> On 20 Mar 2025, at 15:50, Matthias Sohn <matthi...@gmail.com> wrote:
>
> On Thu, Mar 20, 2025 at 4:43 PM Rodion <rodvla...@gmail.com> wrote:
> Hello, when I fetch Gerrit repository I get 'remote: error: internal error'. In gerrit logs I found the following errors:
> [ReceiveCommits-8[receive-commits]-for-SSH git-receive-pack /my/repository (user)] ERROR com.google.gerrit.server.git.receive.ReceiveCommits : ReceiveCommits failed due to NullPointerException java.lang.NullPointerException: change 123456: change not processed by merge strategy at java.base/java.util.Objects.requireNonNull(Objects.java:259) at com.google.gerrit.server.submit.SubmitStrategyListener.checkCommitStatus(SubmitStrategyListener.java:107) at com.google.gerrit.server.submit.SubmitStrategyListener.afterUpdateRepos(SubmitStrategyListener.java:57) at com.google.gerrit.server.update.BatchUpdates.notifyAfterUpdateRepo(BatchUpdates.java:155) at com.google.gerrit.server.update.BatchUpdates.execute(BatchUpdates.java:110) at com.google.gerrit.server.update.SubmissionExecutor.execute(SubmissionExecutor.java:66) at com.google.gerrit.server.submit.MergeOp.integrateIntoHistory(MergeOp.java:934) at com.google.gerrit.server.submit.MergeOp.lambda$merge$2(MergeOp.java:760) at com.google.gerrit.server.update.RetryableChangeAction.lambda$new$0(RetryableChangeAction.java:48) at com.google.gerrit.server.update.RetryableAction.lambda$new$0(RetryableAction.java:94) at com.github.rholder.retry.AttemptTimeLimiters$NoAttemptTimeLimit.call(AttemptTimeLimiters.java:78) at com.github.rholder.retry.Retryer.call(Retryer.java:160) at com.google.gerrit.server.update.RetryHelper.executeWithTimeoutCount(RetryHelper.java:598) at com.google.gerrit.server.update.RetryHelper.execute(RetryHelper.java:541) at com.google.gerrit.server.update.RetryableAction.call(RetryableAction.java:192) at com.google.gerrit.server.update.RetryableChangeAction.call(RetryableChangeAction.java:84) at com.google.gerrit.server.submit.MergeOp.merge(MergeOp.java:769) at com.google.gerrit.server.git.receive.ReceiveCommits.submit(ReceiveCommits.java:3144) at com.google.gerrit.server.git.receive.ReceiveCommits.insertChangesAndPatchSets(ReceiveCommits.java:1199) at com.google.gerrit.server.git.receive.ReceiveCommits.processCommandsUnsafe(ReceiveCommits.java:921) at com.google.gerrit.server.git.receive.ReceiveCommits.processCommands(ReceiveCommits.java:730) at com.google.gerrit.server.git.receive.AsyncReceiveCommits.lambda$preReceive$2(AsyncReceiveCommits.java:386) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317) at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:572) at com.google.gerrit.server.util.RequestScopePropagator.lambda$cleanup$1(RequestScopePropagator.java:187) at com.google.gerrit.server.util.RequestScopePropagator.lambda$context$0(RequestScopePropagator.java:174) at com.google.gerrit.server.util.ThreadLocalRequestScopePropagator.lambda$wrapImpl$0(ThreadLocalRequestScopePropagator.java:47) at com.google.gerrit.server.util.RequestScopePropagator$1.call(RequestScopePropagator.java:85) at com.google.gerrit.server.util.RequestScopePropagator$2.run(RequestScopePropagator.java:116) at com.google.gerrit.server.logging.LoggingContextAwareRunnable.run(LoggingContextAwareRunnable.java:113) at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:572) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317) at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) at com.google.gerrit.server.git.WorkQueue$Task.run(WorkQueue.java:912) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642) at java.base/java.lang.Thread.run(Thread.java:1583)
>

Can you clarify what you mean by ”when I fetch Gerrit” ?
From the stack-trace you’ve posted, I see a ‘git-receive-pack’ which means you were pushing to Gerrit, not fetching.
I believe the [1] has been resolved by Gal in [2] from Gerrit v3.5 onwards: are you running an older EOL version of Gerrit?
If yes, please do upgrade to a supported version, as we provide community-based support based on the T&Cs at [3].

HTH

Luca.

[1] https://groups.google.com/g/repo-discuss/c/F_A-5-cSilM/m/L8t2FL3BAAAJ
[2] https://gerrit-review.googlesource.com/c/gerrit/+/462141
[3] https://www.gerritcodereview.com/support.html#supported-versions


>
> -Matthias
>
>
> --
> --
> To unsubscribe, email repo-discuss...@googlegroups.com
> More info at http://groups.google.com/group/repo-discuss?hl=en
>
> ---
> You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/repo-discuss/440a0a5b-90e7-40d9-8efe-9bef962a4d1bn%40googlegroups.com.
>
> --
> --
> To unsubscribe, email repo-discuss...@googlegroups.com
> More info at http://groups.google.com/group/repo-discuss?hl=en
>
> ---
> You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/repo-discuss/CAKSZd3SXjqPTnjj%3DK3yev_25mHEekLDgO%2BqGuutA%3DyoMx08mmw%40mail.gmail.com.


Rodion

unread,
Mar 21, 2025, 4:19:03 AMMar 21
to Repo and Gerrit Discussion
Sorry for confusing, I was pushing to Gerrit repository.
I'm using Gerrit v3.11.1

четверг, 20 марта 2025 г. в 23:03:54 UTC+3, Luca Milanesio:

Luca Milanesio

unread,
Mar 21, 2025, 4:28:41 AMMar 21
to Repo and Gerrit Discussion, Luca Milanesio

On 21 Mar 2025, at 08:19, Rodion <rodvla...@gmail.com> wrote:

Sorry for confusing, I was pushing to Gerrit repository.
I'm using Gerrit v3.11.1

It must be a different issue then.

I believe what happens is that your push is silently trying to merge a series of changes and some of them are already merged (or reachable) in another branch.

HTH

Luca.

Rodion

unread,
Mar 21, 2025, 7:46:56 AMMar 21
to Repo and Gerrit Discussion
We've recently updated Gerrit from v3.9.2 to v3.11.1. We didn't face this issue before the update. Could there be any changes, that cause this issue in new version?

пятница, 21 марта 2025 г. в 11:28:41 UTC+3, Luca Milanesio:

Dmytro Rodionov

unread,
Mar 28, 2025, 8:00:22 AMMar 28
to Repo and Gerrit Discussion
Good day,

пятница, 21 марта 2025 г. в 09:28:41 UTC+1, Luca Milanesio:

On 21 Mar 2025, at 08:19, Rodion <rodvla...@gmail.com> wrote:

Sorry for confusing, I was pushing to Gerrit repository.
I'm using Gerrit v3.11.1

It must be a different issue then.

 
I believe what happens is that your push is silently trying to merge a series of changes and some of them are already merged (or reachable) in another branch.

We have no indication of this change being present in any of other branches. Change ID and hash are both unique and pointing to only one pull request for every change in relation chain
Manual merge works without issues, why silent merge has different behaviour? I don't see anything about in docs
What could be a reason then, and how can we get to the root of it?

Thank you in advance,
Dmytro Rodionov

Sven Selberg

unread,
Mar 28, 2025, 8:26:22 AMMar 28
to Repo and Gerrit Discussion
On Friday, March 28, 2025 at 1:00:22 PM UTC+1 Dmytro Rodionov wrote:
Good day,

пятница, 21 марта 2025 г. в 09:28:41 UTC+1, Luca Milanesio:

On 21 Mar 2025, at 08:19, Rodion <rodvla...@gmail.com> wrote:

Sorry for confusing, I was pushing to Gerrit repository.
I'm using Gerrit v3.11.1

It must be a different issue then.

 
I believe what happens is that your push is silently trying to merge a series of changes and some of them are already merged (or reachable) in another branch.

We have no indication of this change being present in any of other branches. Change ID and hash are both unique and pointing to only one pull request for every change in relation chain
Manual merge works without issues, why silent merge has different behaviour? I don't see anything about in docs
What could be a reason then, and how can we get to the root of it?

What is the submit-strategy of the repository?
It sounds a lot like Issue 40014054 that I don't think is solved.

Dmytro Rodionov

unread,
Mar 28, 2025, 8:35:21 AMMar 28
to Repo and Gerrit Discussion


пятница, 28 марта 2025 г. в 13:26:22 UTC+1, Sven Selberg:
On Friday, March 28, 2025 at 1:00:22 PM UTC+1 Dmytro Rodionov wrote:
Good day,

пятница, 21 марта 2025 г. в 09:28:41 UTC+1, Luca Milanesio:

On 21 Mar 2025, at 08:19, Rodion <rodvla...@gmail.com> wrote:

Sorry for confusing, I was pushing to Gerrit repository.
I'm using Gerrit v3.11.1

It must be a different issue then.

 
I believe what happens is that your push is silently trying to merge a series of changes and some of them are already merged (or reachable) in another branch.

We have no indication of this change being present in any of other branches. Change ID and hash are both unique and pointing to only one pull request for every change in relation chain
Manual merge works without issues, why silent merge has different behaviour? I don't see anything about in docs
What could be a reason then, and how can we get to the root of it?

What is the submit-strategy of the repository?
It sounds a lot like Issue 40014054 that I don't think is solved.

We use the default strategy "Merge If Necessary", not the "Fast Forward Only" from the issue

Luca Milanesio

unread,
Mar 28, 2025, 9:03:25 AMMar 28
to Repo and Gerrit Discussion, Luca Milanesio

On 28 Mar 2025, at 12:35, Dmytro Rodionov <smpli...@gmail.com> wrote:



пятница, 28 марта 2025 г. в 13:26:22 UTC+1, Sven Selberg:
On Friday, March 28, 2025 at 1:00:22 PM UTC+1 Dmytro Rodionov wrote:
Good day,

пятница, 21 марта 2025 г. в 09:28:41 UTC+1, Luca Milanesio:

On 21 Mar 2025, at 08:19, Rodion <rodvla...@gmail.com> wrote:

Sorry for confusing, I was pushing to Gerrit repository.
I'm using Gerrit v3.11.1

It must be a different issue then.

 
I believe what happens is that your push is silently trying to merge a series of changes and some of them are already merged (or reachable) in another branch.

We have no indication of this change being present in any of other branches. Change ID and hash are both unique and pointing to only one pull request for every change in relation chain
Manual merge works without issues, why silent merge has different behaviour? I don't see anything about in docs
What could be a reason then, and how can we get to the root of it?

What is the submit-strategy of the repository?
It sounds a lot like Issue 40014054 that I don't think is solved.

We use the default strategy "Merge If Necessary", not the "Fast Forward Only" from the issue

I could be a new issue then.

Luca.

Dmytro Rodionov

unread,
Mar 28, 2025, 9:39:49 AMMar 28
to Repo and Gerrit Discussion


пятница, 28 марта 2025 г. в 14:03:25 UTC+1, Luca Milanesio:

On 28 Mar 2025, at 12:35, Dmytro Rodionov <smpli...@gmail.com> wrote:



пятница, 28 марта 2025 г. в 13:26:22 UTC+1, Sven Selberg:
On Friday, March 28, 2025 at 1:00:22 PM UTC+1 Dmytro Rodionov wrote:
Good day,

пятница, 21 марта 2025 г. в 09:28:41 UTC+1, Luca Milanesio:

On 21 Mar 2025, at 08:19, Rodion <rodvla...@gmail.com> wrote:

Sorry for confusing, I was pushing to Gerrit repository.
I'm using Gerrit v3.11.1

It must be a different issue then.

 
I believe what happens is that your push is silently trying to merge a series of changes and some of them are already merged (or reachable) in another branch.

We have no indication of this change being present in any of other branches. Change ID and hash are both unique and pointing to only one pull request for every change in relation chain
Manual merge works without issues, why silent merge has different behaviour? I don't see anything about in docs
What could be a reason then, and how can we get to the root of it?

What is the submit-strategy of the repository?
It sounds a lot like Issue 40014054 that I don't think is solved.

We use the default strategy "Merge If Necessary", not the "Fast Forward Only" from the issue

I could be a new issue then.

It could be. But we don't know why this happens and therefore unable to find steps to reproduce, in order to create a proper issue.

The stacktrace `java.lang.NullPointerException: change 69038: change not processed by merge strategy` tells short to nothing. 
Like, why change was not processed? There are no other relevant errors in logs.

Can you help us in any way, because we are grasping at straws here 
A hint, suggestion, general direction what to look for would be great

Thank you

Luca Milanesio

unread,
Mar 28, 2025, 11:02:23 AMMar 28
to Repo and Gerrit Discussion, Luca Milanesio

On 28 Mar 2025, at 13:39, Dmytro Rodionov <smpli...@gmail.com> wrote:



пятница, 28 марта 2025 г. в 14:03:25 UTC+1, Luca Milanesio:

On 28 Mar 2025, at 12:35, Dmytro Rodionov <smpli...@gmail.com> wrote:



пятница, 28 марта 2025 г. в 13:26:22 UTC+1, Sven Selberg:
On Friday, March 28, 2025 at 1:00:22 PM UTC+1 Dmytro Rodionov wrote:
Good day,

пятница, 21 марта 2025 г. в 09:28:41 UTC+1, Luca Milanesio:

On 21 Mar 2025, at 08:19, Rodion <rodvla...@gmail.com> wrote:

Sorry for confusing, I was pushing to Gerrit repository.
I'm using Gerrit v3.11.1

It must be a different issue then.

 
I believe what happens is that your push is silently trying to merge a series of changes and some of them are already merged (or reachable) in another branch.

We have no indication of this change being present in any of other branches. Change ID and hash are both unique and pointing to only one pull request for every change in relation chain
Manual merge works without issues, why silent merge has different behaviour? I don't see anything about in docs
What could be a reason then, and how can we get to the root of it?

What is the submit-strategy of the repository?
It sounds a lot like Issue 40014054 that I don't think is solved.

We use the default strategy "Merge If Necessary", not the "Fast Forward Only" from the issue

I could be a new issue then.

It could be. But we don't know why this happens and therefore unable to find steps to reproduce, in order to create a proper issue.

Then I believe you are the only ones that can debug the issue.
I guess the repository isn’t public.

Luca.

Amir Zavelghorba

unread,
Mar 31, 2025, 2:41:10 AMMar 31
to Luca Milanesio, Repo and Gerrit Discussion

I will send you the answer as soon as possible.


در تاریخ جمعه ۲۸ مارس ۲۰۲۵، ۱۸:۳۲ Luca Milanesio <luca.mi...@gmail.com> نوشت:
To view this discussion visit https://groups.google.com/d/msgid/repo-discuss/7A41A4D6-C960-4500-84A4-607B195E26F5%40gmail.com.

Denis Khabensky

unread,
Apr 14, 2025, 8:59:35 AMApr 14
to Repo and Gerrit Discussion
Nice to meet you, guys!

Finally, I was able to reproduce the issue.

Here are the steps, 100% reproducible on demo repository.
Its submit strategy is "Rebase if necessary".

git fetch origin master
git checkout origin/master -b demo_master

echo "common_rev" > demo_common_file && git add demo_common_file && git commit -m "common_rev"
git push origin HEAD:refs/for/master
# merge change via gerrit web interface

echo "master_rev" > demo_master_file && git add demo_master_file && git commit -m "master_rev"
git push origin HEAD:refs/for/master
# merge change via gerrit web interface

git checkout HEAD~1 -b demo_external

echo "rev_to_merge_1" > demo_external_file && git add demo_external_file && git commit -m "external_rev_1"

echo "rev_to_merge_2" >> demo_external_file && git add demo_external_file && git commit -m "external_rev_2 (dependent on external_rev_1)"

git checkout demo_master
git merge --ff -m "merge external into master" demo_external
git push origin HEAD:refs/for/master%submit
# internal error

While that happens, I see following errors/warning in logs:

ERROR: ReceiveCommits failed due to NullPointerException
java.lang.NullPointerException: change 69604: change not processed by merge strategy
ERROR: error while processing push
java.util.concurrent.ExecutionException: java.lang.NullPointerException: change 69604: change not processed by merge strategy

   at java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122)
   at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:191)
   at com.google.gerrit.server.git.receive.AsyncReceiveCommits.preReceive(AsyncReceiveCommits.java:407)
   at com.google.gerrit.server.git.receive.AsyncReceiveCommits.lambda$asHook$0(AsyncReceiveCommits.java:351)
   at org.eclipse.jgit.transport.ReceivePack.service(ReceivePack.java:2287)
   at org.eclipse.jgit.transport.ReceivePack.receive(ReceivePack.java:2200)
   at com.google.gerrit.sshd.commands.Receive.runImpl(Receive.java:98)
   at com.google.gerrit.sshd.AbstractGitCommand.service(AbstractGitCommand.java:109)
   at com.google.gerrit.sshd.AbstractGitCommand$1.run(AbstractGitCommand.java:74)
   at com.google.gerrit.sshd.BaseCommand$TaskThunk.run(BaseCommand.java:492)
   at com.google.gerrit.server.logging.LoggingContextAwareRunnable.run(LoggingContextAwareRunnable.java:113)
   at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:572)
   at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317)
   at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
   at com.google.gerrit.server.git.WorkQueue$Task.run(WorkQueue.java:912)
   at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
   at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
   at java.base/java.lang.Thread.run(Thread.java:1583)
Caused by: java.lang.NullPointerException: change 69604: change not processed by merge strategy
WARN: MultiProgressMonitor worker did not call end() before returning


I also found that the state gerrit gets in is persistent: I cannot merge this chain both via %submit magic and web interface.
While merging through web interface I see following error:

ERROR: Error in POST /changes/dhabensky-test~69605/revisions/1/submit (view: restapi.change.Submit): NullPointerException [CONTEXT project="dhabensky-test" request="REST /changes/*/revisions/*/submit" ]
java.lang.NullPointerException: change 69604: change not processed by merge strategy

   at java.base/java.util.Objects.requireNonNull(Objects.java:259)
   at com.google.gerrit.server.submit.SubmitStrategyListener.checkCommitStatus(SubmitStrategyListener.java:107)
   at com.google.gerrit.server.submit.SubmitStrategyListener.afterUpdateRepos(SubmitStrategyListener.java:57)
   at com.google.gerrit.server.update.BatchUpdates.notifyAfterUpdateRepo(BatchUpdates.java:155)
   at com.google.gerrit.server.update.BatchUpdates.execute(BatchUpdates.java:110)
   at com.google.gerrit.server.update.SubmissionExecutor.execute(SubmissionExecutor.java:66)
   at com.google.gerrit.server.submit.MergeOp.integrateIntoHistory(MergeOp.java:934)
   at com.google.gerrit.server.submit.MergeOp.lambda$merge$2(MergeOp.java:760)
   at com.google.gerrit.server.update.RetryableChangeAction.lambda$new$0(RetryableChangeAction.java:48)
   at com.google.gerrit.server.update.RetryableAction.lambda$new$0(RetryableAction.java:94)
   at com.github.rholder.retry.AttemptTimeLimiters$NoAttemptTimeLimit.call(AttemptTimeLimiters.java:78)
   at com.github.rholder.retry.Retryer.call(Retryer.java:160)
   at com.google.gerrit.server.update.RetryHelper.executeWithTimeoutCount(RetryHelper.java:598)
   at com.google.gerrit.server.update.RetryHelper.execute(RetryHelper.java:541)
   at com.google.gerrit.server.update.RetryableAction.call(RetryableAction.java:192)
   at com.google.gerrit.server.update.RetryableChangeAction.call(RetryableChangeAction.java:84)
   at com.google.gerrit.server.submit.MergeOp.merge(MergeOp.java:769)
   at com.google.gerrit.server.restapi.change.Submit.mergeChange(Submit.java:230)
   at com.google.gerrit.server.restapi.change.Submit.apply(Submit.java:206)
   at com.google.gerrit.server.restapi.change.Submit.apply(Submit.java:98)
   at com.google.gerrit.httpd.restapi.RestApiServlet.lambda$invokeRestModifyViewWithRetry$6(RestApiServlet.java:853)

   at com.google.gerrit.server.update.RetryableAction.lambda$new$0(RetryableAction.java:94)
   at com.github.rholder.retry.AttemptTimeLimiters$NoAttemptTimeLimit.call(AttemptTimeLimiters.java:78)
   at com.github.rholder.retry.Retryer.call(Retryer.java:160)
   at com.google.gerrit.server.update.RetryHelper.executeWithTimeoutCount(RetryHelper.java:598)
   at com.google.gerrit.server.update.RetryHelper.execute(RetryHelper.java:541)
   at com.google.gerrit.server.update.RetryableAction.call(RetryableAction.java:192)
   at com.google.gerrit.httpd.restapi.RestApiServlet.invokeRestEndpointWithRetry(RestApiServlet.java:928)
   at com.google.gerrit.httpd.restapi.RestApiServlet.invokeRestModifyViewWithRetry(RestApiServlet.java:848)
   at com.google.gerrit.httpd.restapi.RestApiServlet.service(RestApiServlet.java:533)
   at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
   at com.google.inject.servlet.ServletDefinition.doServiceImpl(ServletDefinition.java:293)
   at com.google.inject.servlet.ServletDefinition.doService(ServletDefinition.java:283)
   at com.google.inject.servlet.ServletDefinition.service(ServletDefinition.java:184)
   at com.google.inject.servlet.ManagedServletPipeline.service(ManagedServletPipeline.java:89)
   at com.google.inject.servlet.FilterChainInvocation.doFilter(FilterChainInvocation.java:85)
   at com.google.gerrit.httpd.raw.StaticModule$PolyGerritFilter.doFilter(StaticModule.java:403)
   at com.google.inject.servlet.FilterChainInvocation.doFilter(FilterChainInvocation.java:82)
   at com.google.gerrit.httpd.GetUserFilter.doFilter(GetUserFilter.java:92)
   at com.google.inject.servlet.FilterChainInvocation.doFilter(FilterChainInvocation.java:82)
   at com.google.gerrit.httpd.RequireSslFilter.doFilter(RequireSslFilter.java:72)
   at com.google.inject.servlet.FilterChainInvocation.doFilter(FilterChainInvocation.java:82)
   at com.google.gerrit.httpd.RunAsFilter.doFilter(RunAsFilter.java:120)
   at com.google.inject.servlet.FilterChainInvocation.doFilter(FilterChainInvocation.java:82)
   at com.google.gerrit.httpd.SetThreadNameFilter.doFilter(SetThreadNameFilter.java:62)
   at com.google.inject.servlet.FilterChainInvocation.doFilter(FilterChainInvocation.java:82)
   at com.google.gerrit.httpd.AllRequestFilter$FilterProxy$1.doFilter(AllRequestFilter.java:139)
   at com.googlesource.gerrit.plugins.readonly.ReadOnly.doFilter(ReadOnly.java:79)
   at com.google.gerrit.httpd.AllRequestFilter$FilterProxy$1.doFilter(AllRequestFilter.java:135)
   at com.ericsson.gerrit.plugins.highavailability.XGerritInstanceFilter.doFilter(XGerritInstanceFilter.java:51)
   at com.google.gerrit.httpd.AllRequestFilter$FilterProxy$1.doFilter(AllRequestFilter.java:135)
   at com.google.gerrit.httpd.AllowRenderInFrameFilter.doFilter(AllowRenderInFrameFilter.java:56)
   at com.google.gerrit.httpd.AllRequestFilter$FilterProxy$1.doFilter(AllRequestFilter.java:135)
   at com.google.gerrit.httpd.AllRequestFilter$FilterProxy.doFilter(AllRequestFilter.java:141)
   at com.google.inject.servlet.FilterChainInvocation.doFilter(FilterChainInvocation.java:82)
   at com.google.gerrit.httpd.RequestCleanupFilter.doFilter(RequestCleanupFilter.java:60)
   at com.google.inject.servlet.FilterChainInvocation.doFilter(FilterChainInvocation.java:82)
   at com.google.gerrit.httpd.RequestMetricsFilter.doFilter(RequestMetricsFilter.java:92)
   at com.google.inject.servlet.FilterChainInvocation.doFilter(FilterChainInvocation.java:82)
   at com.google.gerrit.httpd.RequestContextFilter.doFilter(RequestContextFilter.java:64)
   at com.google.inject.servlet.FilterChainInvocation.doFilter(FilterChainInvocation.java:82)
   at com.google.inject.servlet.ManagedFilterPipeline.dispatch(ManagedFilterPipeline.java:121)
   at com.google.inject.servlet.GuiceFilter.doFilter(GuiceFilter.java:133)
   at org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:193)
   at org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1626)
   at com.googlesource.gerrit.plugins.saml.SamlWebFilter.doFilter(SamlWebFilter.java:165)
   at org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:193)
   at org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1626)
   at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:552)
   at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
   at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1624)
   at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
   at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1440)
   at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
   at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:505)
   at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1594)
   at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
   at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1355)
   at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
   at org.eclipse.jetty.server.handler.RequestLogHandler.handle(RequestLogHandler.java:54)
   at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
   at org.eclipse.jetty.server.Server.handle(Server.java:516)
   at org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:487)
   at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:732)
   at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:479)
   at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:277)
   at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
   at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105)
   at org.eclipse.jetty.io.ChannelEndPoint$1.run(ChannelEndPoint.java:104)
   at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:338)
   at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:315)
   at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:173)
   at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:131)
   at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:409)
   at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:883)
   at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1034)
   at java.base/java.lang.Thread.run(Thread.java:1583)


So the problem lies in change  "external_rev_2 (dependent on external_rev_1)" not getting processed for some reason.
I can guess the root cause is gerrit trying to process the change individually, not inside the relation chain.

In any case, I hope this reproducer will be enough for you to further investigate the problem.

As I see, this is a regression introduced somewhere between 3.9.2 and 3.11.1

Denis

пятница, 28 марта 2025 г. в 18:02:23 UTC+3, Luca Milanesio:

Björn Pedersen

unread,
Apr 14, 2025, 9:54:31 AMApr 14
to Repo and Gerrit Discussion
Denis Khabensky schrieb am Montag, 14. April 2025 um 14:59:35 UTC+2:
Nice to meet you, guys!

Finally, I was able to reproduce the issue.

Here are the steps, 100% reproducible on demo repository.
Its submit strategy is "Rebase if necessary".

git fetch origin master
git checkout origin/master -b demo_master

echo "common_rev" > demo_common_file && git add demo_common_file && git commit -m "common_rev"
git push origin HEAD:refs/for/master
# merge change via gerrit web interface

echo "master_rev" > demo_master_file && git add demo_master_file && git commit -m "master_rev"
git push origin HEAD:refs/for/master
# merge change via gerrit web interface

git checkout HEAD~1 -b demo_external

echo "rev_to_merge_1" > demo_external_file && git add demo_external_file && git commit -m "external_rev_1"

echo "rev_to_merge_2" >> demo_external_file && git add demo_external_file && git commit -m "external_rev_2 (dependent on external_rev_1)"

git checkout demo_master
git merge --ff -m "merge external into master" demo_external

Using merges with rebases is tricky on the commandline already, so this  workflow is incompatible with the selected commit strategy.  Gerrit tries to rebase each commit and this fails.
It is probably a bug that a null pointer exception is  raised, but that this does not work is expected.

Denis Khabensky

unread,
Apr 14, 2025, 10:24:47 AMApr 14
to Repo and Gerrit Discussion
> Using merges with rebases is tricky on the commandline already, so this  workflow is incompatible with the selected commit strategy.

This sounds true and I agree that in general this can be tricky.

But, look for this particular case (syncing & merging code between our and partner remotes):
- git checkout origin/master
- git merge external/external_branch
- git push origin/master
- git push external/external_branch

In this case push is always fast-forward and it should NOT fail.
This was the behaviour on 3.9.2 and seems it is broken on 3.11.1

Regarding chosen submit strategy:

This repository is used both by developers and automatic code sync.
For developers "rebase if necessary" is more comfortable (does not require additional manual actions compared with "fast forward only").
For code sync "fast forward only" would be the right choice. But for the sake of developers' comfort, actual submit type is "fast forward only". 

It would be great if we could override submit type per submission to use "fast forward only" explicitly in code sync tool.
What we do now, is pulling-then-pushing, so actually achieving fast-forward in 99% cases.  



понедельник, 14 апреля 2025 г. в 16:54:31 UTC+3, Björn Pedersen:

Denis Khabensky

unread,
Apr 28, 2025, 11:56:52 AMApr 28
to Repo and Gerrit Discussion
Dear Björn, Luca, any updates here?

This seems like 100% legitimate case that was broken, please share your vision.

понедельник, 14 апреля 2025 г. в 17:24:47 UTC+3, Denis Khabensky:

Björn Pedersen

unread,
May 2, 2025, 7:48:01 AMMay 2
to Repo and Gerrit Discussion
Denis Khabensky schrieb am Montag, 14. April 2025 um 16:24:47 UTC+2:
> Using merges with rebases is tricky on the commandline already, so this  workflow is incompatible with the selected commit strategy.

This sounds true and I agree that in general this can be tricky.

But, look for this particular case (syncing & merging code between our and partner remotes):
- git checkout origin/master
- git merge external/external_branch
- git push origin/master
- git push external/external_branch

In this case push is always fast-forward and it should NOT fail.
This was the behaviour on 3.9.2 and seems it is broken on 3.11.1

Regarding chosen submit strategy:

This repository is used both by developers and automatic code sync.
For developers "rebase if necessary" is more comfortable (does not require additional manual actions compared with "fast forward only").
For code sync "fast forward only" would be the right choice. But for the sake of developers' comfort, actual submit type is "fast forward only". 

It would be great if we could override submit type per submission to use "fast forward only" explicitly in code sync tool.
What we do now, is pulling-then-pushing, so actually achieving fast-forward in 99% cases.  



This can be achieved via well-designed prolog rules

e.g. 
```
% if a topic is set, switch to  rebase_always, as we
% already enforce common submit  via SubmitWholeTopic.
% this works around the limitations for cherry-pick if the
% change series contains internal conflicts.
submit_type(rebase_always) :-
    gerrit:change_topic(T),T \== "",
    !.
% Otherwise use the default from the project config.
submit_type(T) :- gerrit:project_default_submit_type(T).
```

set the strategy to rebase-always if a  topic is set, and uses the default otherwise.

You would just match e.g. on the bot-user instead and set to fast-forward only
Reply all
Reply to author
Forward
0 new messages