[Issue 15194] Ensuring that meta refs are always pushed together with their respective change ref

180 views
Skip to first unread message

Thomas Dräbing

unread,
Dec 3, 2021, 9:36:44 AM12/3/21
to Repo and Gerrit Discussion
Hi all,

some time ago I opened issue 15194 [1]. The issue is that for huge, busy projects it can happen that a replication push contains the change ref (refs/changes/01/1/1), but not the meta ref of the change (refs/changes/01/1/meta). If the replication delay is significant, it can be minutes until the meta ref reaches the replica. Since the meta ref is required to fetch a change due to permission checks, clients fail to fetch the change even after the ref-replicated event was fired for the change.

I pushed a change [2] that fixes that by always adding the meta ref to the push task, if a change ref is being pushed. This solution however is not very nice. Often enough the meta ref does not have to be replicated. While jgit won't push it, if the remote ref is up-to-date, adding it to the task already might impact performance.

Matthias had the proposal that instead of having separate ref-updated events for the change ref and the meta-ref, which in turn lead to them being scheduled for replication, to have a single event listing both refs, since they are created with a batch ref update anyway. This would solve the duplicate addition of the meta ref in my change, but would require a change in Gerrit core that will likely affect other areas.

What do you think? Reviews and ideas are welcome!

Thanks,
Thomas


Luca Milanesio

unread,
Dec 3, 2021, 4:30:15 PM12/3/21
to Repo and Gerrit Discussion, Luca Milanesio, Thomas Dräbing

On 3 Dec 2021, at 14:36, Thomas Dräbing <thomas....@gmail.com> wrote:

Hi all,

some time ago I opened issue 15194 [1]. The issue is that for huge, busy projects it can happen that a replication push contains the change ref (refs/changes/01/1/1), but not the meta ref of the change (refs/changes/01/1/meta). If the replication delay is significant, it can be minutes until the meta ref reaches the replica. Since the meta ref is required to fetch a change due to permission checks, clients fail to fetch the change even after the ref-replicated event was fired for the change.

I pushed a change [2] that fixes that by always adding the meta ref to the push task, if a change ref is being pushed. This solution however is not very nice. Often enough the meta ref does not have to be replicated. While jgit won't push it, if the remote ref is up-to-date, adding it to the task already might impact performance.

Matthias had the proposal that instead of having separate ref-updated events for the change ref and the meta-ref, which in turn lead to them being scheduled for replication, to have a single event listing both refs, since they are created with a batch ref update anyway. This would solve the duplicate addition of the meta ref in my change, but would require a change in Gerrit core that will likely affect other areas.

I agree with Matthias’s proposal, however, we should formulate it in a forward-compatible way.

One idea could be listing the full set of refs included in the batch ref-update in the ref-updated event but as a separate field.
For those who are still looking at the old field, they’ll get two separate events. For those looking at the new field, they’ll get both events in one go.

The drawback is that you may receive one event twice, which is a minor issue IMHO.

WDYT?

Luca.

--
--
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 on the web visit https://groups.google.com/d/msgid/repo-discuss/CAG7bb4AekueTeECXxD2ZQBB0LYXh9uab9SYEyXPnk_U6ARNLOg%40mail.gmail.com.

Nasser Grainawi

unread,
Dec 3, 2021, 4:53:40 PM12/3/21
to Luca Milanesio, Repo and Gerrit Discussion, Thomas Dräbing
On Dec 3, 2021, at 2:30 PM, Luca Milanesio <luca.mi...@gmail.com> wrote:



On 3 Dec 2021, at 14:36, Thomas Dräbing <thomas....@gmail.com> wrote:

Hi all,

some time ago I opened issue 15194 [1]. The issue is that for huge, busy projects it can happen that a replication push contains the change ref (refs/changes/01/1/1), but not the meta ref of the change (refs/changes/01/1/meta). If the replication delay is significant, it can be minutes until the meta ref reaches the replica. Since the meta ref is required to fetch a change due to permission checks, clients fail to fetch the change even after the ref-replicated event was fired for the change.

I pushed a change [2] that fixes that by always adding the meta ref to the push task, if a change ref is being pushed. This solution however is not very nice. Often enough the meta ref does not have to be replicated. While jgit won't push it, if the remote ref is up-to-date, adding it to the task already might impact performance.

Matthias had the proposal that instead of having separate ref-updated events for the change ref and the meta-ref, which in turn lead to them being scheduled for replication, to have a single event listing both refs, since they are created with a batch ref update anyway. This would solve the duplicate addition of the meta ref in my change, but would require a change in Gerrit core that will likely affect other areas.

I agree with Matthias’s proposal, however, we should formulate it in a forward-compatible way.

One idea could be listing the full set of refs included in the batch ref-update in the ref-updated event but as a separate field.
For those who are still looking at the old field, they’ll get two separate events. For those looking at the new field, they’ll get both events in one go.

I don’t think an event/class that’s singular (ref-updated) should have information about multiple refs. That’s going to lead to confusion.

I do think it would be great to have a new refs-updated event with a list of all updated refs and I think that particularly makes sense for the batch update use cases.


The drawback is that you may receive one event twice, which is a minor issue IMHO.

WDYT?

Luca.


-- 
-- 
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 on the web visit https://groups.google.com/d/msgid/repo-discuss/CAG7bb4AekueTeECXxD2ZQBB0LYXh9uab9SYEyXPnk_U6ARNLOg%40mail.gmail.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.

Matthias Sohn

unread,
Dec 3, 2021, 5:45:19 PM12/3/21
to Nasser Grainawi, Luca Milanesio, Repo and Gerrit Discussion, Thomas Dräbing
On Fri, Dec 3, 2021 at 10:54 PM Nasser Grainawi <nas...@codeaurora.org> wrote:

On Dec 3, 2021, at 2:30 PM, Luca Milanesio <luca.mi...@gmail.com> wrote:



On 3 Dec 2021, at 14:36, Thomas Dräbing <thomas....@gmail.com> wrote:

Hi all,

some time ago I opened issue 15194 [1]. The issue is that for huge, busy projects it can happen that a replication push contains the change ref (refs/changes/01/1/1), but not the meta ref of the change (refs/changes/01/1/meta). If the replication delay is significant, it can be minutes until the meta ref reaches the replica. Since the meta ref is required to fetch a change due to permission checks, clients fail to fetch the change even after the ref-replicated event was fired for the change.

I pushed a change [2] that fixes that by always adding the meta ref to the push task, if a change ref is being pushed. This solution however is not very nice. Often enough the meta ref does not have to be replicated. While jgit won't push it, if the remote ref is up-to-date, adding it to the task already might impact performance.

Matthias had the proposal that instead of having separate ref-updated events for the change ref and the meta-ref, which in turn lead to them being scheduled for replication, to have a single event listing both refs, since they are created with a batch ref update anyway. This would solve the duplicate addition of the meta ref in my change, but would require a change in Gerrit core that will likely affect other areas.

I agree with Matthias’s proposal, however, we should formulate it in a forward-compatible way.

One idea could be listing the full set of refs included in the batch ref-update in the ref-updated event but as a separate field.
For those who are still looking at the old field, they’ll get two separate events. For those looking at the new field, they’ll get both events in one go.

I don’t think an event/class that’s singular (ref-updated) should have information about multiple refs. That’s going to lead to confusion.

I do think it would be great to have a new refs-updated event with a list of all updated refs and I think that particularly makes sense for the batch update use cases.

+1, we could introduce a new refs-updated event and deprecate the old ref-updated event and remove it in a future release.
This way existing consumers of the old event have time to migrate.

Sending all refs in the old ref-updated event would be confusing (didn't check if this could be done in a compatible way)
and send the same information multiple times. If e.g. a batch ref update updates 5 refs we would send 5 events each
containing all the 5 updated refs. If we introduce a new refs-updated event we send 5 ref-updated events each containing
a single ref and 1 refs-updated event containing all 5.

I think that using the same transaction boundaries for (batch) ref update and for replication has the potential to eliminate
a class of consistency problems like the one Thomas wants to fix.

 

Thomas Dräbing

unread,
Dec 8, 2021, 2:22:42 AM12/8/21
to Matthias Sohn, Nasser Grainawi, Luca Milanesio, Repo and Gerrit Discussion
On Fri, 3 Dec 2021 at 23:45, Matthias Sohn <matthi...@gmail.com> wrote:
On Fri, Dec 3, 2021 at 10:54 PM Nasser Grainawi <nas...@codeaurora.org> wrote:

On Dec 3, 2021, at 2:30 PM, Luca Milanesio <luca.mi...@gmail.com> wrote:



On 3 Dec 2021, at 14:36, Thomas Dräbing <thomas....@gmail.com> wrote:

Hi all,

some time ago I opened issue 15194 [1]. The issue is that for huge, busy projects it can happen that a replication push contains the change ref (refs/changes/01/1/1), but not the meta ref of the change (refs/changes/01/1/meta). If the replication delay is significant, it can be minutes until the meta ref reaches the replica. Since the meta ref is required to fetch a change due to permission checks, clients fail to fetch the change even after the ref-replicated event was fired for the change.

I pushed a change [2] that fixes that by always adding the meta ref to the push task, if a change ref is being pushed. This solution however is not very nice. Often enough the meta ref does not have to be replicated. While jgit won't push it, if the remote ref is up-to-date, adding it to the task already might impact performance.

Matthias had the proposal that instead of having separate ref-updated events for the change ref and the meta-ref, which in turn lead to them being scheduled for replication, to have a single event listing both refs, since they are created with a batch ref update anyway. This would solve the duplicate addition of the meta ref in my change, but would require a change in Gerrit core that will likely affect other areas.

I agree with Matthias’s proposal, however, we should formulate it in a forward-compatible way.

One idea could be listing the full set of refs included in the batch ref-update in the ref-updated event but as a separate field.
For those who are still looking at the old field, they’ll get two separate events. For those looking at the new field, they’ll get both events in one go.

I don’t think an event/class that’s singular (ref-updated) should have information about multiple refs. That’s going to lead to confusion.

I do think it would be great to have a new refs-updated event with a list of all updated refs and I think that particularly makes sense for the batch update use cases.

+1, we could introduce a new refs-updated event and deprecate the old ref-updated event and remove it in a future release.
This way existing consumers of the old event have time to migrate.

Sending all refs in the old ref-updated event would be confusing (didn't check if this could be done in a compatible way)
and send the same information multiple times. If e.g. a batch ref update updates 5 refs we would send 5 events each
containing all the 5 updated refs. If we introduce a new refs-updated event we send 5 ref-updated events each containing
a single ref and 1 refs-updated event containing all 5.

I think that using the same transaction boundaries for (batch) ref update and for replication has the potential to eliminate
a class of consistency problems like the one Thomas wants to fix.

 I agree with Nasser and Matthias on this. There should be options to enable either or both of the events to support components that still use the ref-updated event and components that use refs-updated events at the same time, e.g. Jenkins with gerrit-trigger plugin, which still listens to ref-updated, and the replication plugin, which might already use the refs-updated event.

I will have a look at that and push a change adding the refs-updated event as soon as I have something working.

Sven Selberg

unread,
Dec 8, 2021, 2:42:08 AM12/8/21
to Repo and Gerrit Discussion
On Wednesday, December 8, 2021 at 8:22:42 AM UTC+1 thomas....@gmail.com wrote:
On Fri, 3 Dec 2021 at 23:45, Matthias Sohn <matthi...@gmail.com> wrote:
On Fri, Dec 3, 2021 at 10:54 PM Nasser Grainawi <nas...@codeaurora.org> wrote:

On Dec 3, 2021, at 2:30 PM, Luca Milanesio <luca.mi...@gmail.com> wrote:



On 3 Dec 2021, at 14:36, Thomas Dräbing <thomas....@gmail.com> wrote:

Hi all,

some time ago I opened issue 15194 [1]. The issue is that for huge, busy projects it can happen that a replication push contains the change ref (refs/changes/01/1/1), but not the meta ref of the change (refs/changes/01/1/meta). If the replication delay is significant, it can be minutes until the meta ref reaches the replica. Since the meta ref is required to fetch a change due to permission checks, clients fail to fetch the change even after the ref-replicated event was fired for the change.

I pushed a change [2] that fixes that by always adding the meta ref to the push task, if a change ref is being pushed. This solution however is not very nice. Often enough the meta ref does not have to be replicated. While jgit won't push it, if the remote ref is up-to-date, adding it to the task already might impact performance.

Matthias had the proposal that instead of having separate ref-updated events for the change ref and the meta-ref, which in turn lead to them being scheduled for replication, to have a single event listing both refs, since they are created with a batch ref update anyway. This would solve the duplicate addition of the meta ref in my change, but would require a change in Gerrit core that will likely affect other areas.

I agree with Matthias’s proposal, however, we should formulate it in a forward-compatible way.

One idea could be listing the full set of refs included in the batch ref-update in the ref-updated event but as a separate field.
For those who are still looking at the old field, they’ll get two separate events. For those looking at the new field, they’ll get both events in one go.

I don’t think an event/class that’s singular (ref-updated) should have information about multiple refs. That’s going to lead to confusion.

I do think it would be great to have a new refs-updated event with a list of all updated refs and I think that particularly makes sense for the batch update use cases.

+1, we could introduce a new refs-updated event and deprecate the old ref-updated event and remove it in a future release.
This way existing consumers of the old event have time to migrate.

Sending all refs in the old ref-updated event would be confusing (didn't check if this could be done in a compatible way)
and send the same information multiple times. If e.g. a batch ref update updates 5 refs we would send 5 events each
containing all the 5 updated refs. If we introduce a new refs-updated event we send 5 ref-updated events each containing
a single ref and 1 refs-updated event containing all 5.

I think that using the same transaction boundaries for (batch) ref update and for replication has the potential to eliminate
a class of consistency problems like the one Thomas wants to fix.

 I agree with Nasser and Matthias on this. There should be options to enable either or both of the events to support components that still use the ref-updated event and components that use refs-updated events at the same time, e.g. Jenkins with gerrit-trigger plugin, which still listens to ref-updated, and the replication plugin, which might already use the refs-updated event.

I will have a look at that and push a change adding the refs-updated event as soon as I have something working.

When batch-updates need to be replicated together, is it ever something other than, 1 ref + 0...n meta-ref?

To cater to this case and keep the old ref-updated event backwards compatible (for all but meta refs, which there shouldn't be that many "external" consumers of) how about

1. Update the ref-update events with field metaRefUpdate.
or
2. To cater to the case where only the meta-ref is updated but not the patchset, we could add metaRefUpdate to ref-update event but also introduce a new type "meta-ref-update" for the "only meta-ref" case.
     That way existing consumers, who are already filtering for type "ref-update", wont have to deal with the "only meta-ref update" case. 

An additional benefit is that we could prioritize meta-ref-updates in replication so that f.i. ACL changes are more likely to be replicated before other other ref-updates.

Just a thought.

Thomas Dräbing

unread,
Dec 10, 2021, 3:26:04 AM12/10/21
to Sven Selberg, Repo and Gerrit Discussion
To be honest, I am not too familiar with where BatchRefUpdate is used exactly. A quick git grep shows that it is used in a lot of places concerning notedb, e.g. updates of groups and accounts. While we didn't have any consistency issues in that regard so far after replication, I would naively expect that if BatchRefUpdate is used to update the notedb, it would be favourable to know about the complete update in an event, be it for replication or another usecase. Also in those cases there is no change-ref/meta-ref pair, but e.g. in an account update it is the update of refs/users/... and refs/meta/external-ids.
 
To cater to this case and keep the old ref-updated event backwards compatible (for all but meta refs, which there shouldn't be that many "external" consumers of) how about

There is at least one big consumer and that is the replication plugin, which most of the time also wants to replicate meta-refs. Also, ref-updated is fired e.g. if a notedb ref like refs/users/... was updated. This is likely also not relevant for a lot of external consumers, but still an updated ref.
 
1. Update the ref-update events with field metaRefUpdate.

As described in my previous comments, this might not be a valid and well described field name for all cases where a BatchRefUpdate is performed.
 
or
2. To cater to the case where only the meta-ref is updated but not the patchset, we could add metaRefUpdate to ref-update event but also introduce a new type "meta-ref-update" for the "only meta-ref" case.
     That way existing consumers, who are already filtering for type "ref-update", wont have to deal with the "only meta-ref update" case. 

This would also require the adaptation of quite some event listeners. Also logically there should then be a meta-ref-update event, even if a change ref is updated at the same time, because maybe a listener is only interested in meta-refs. So we would fire additional events with duplicated data.
 
An additional benefit is that we could prioritize meta-ref-updates in replication so that f.i. ACL changes are more likely to be replicated before other other ref-updates.

We would rather have to prioritise the firing of the events, meta-ref before change-ref, since the replication plugin will collect refs for a push for a configured amount of time after the first ref-updated event. What happened in the issue we saw was, that on a busy project, if the ref-updated for the change ref was received first and the ref-updated event of the meta ref only later after the push request was sent out, they were not replicated at the same time. It might be a solution to order the event firing to fire ref-updated for the meta-ref first. I am not sure if that wouldn't cause different issues.

I still think it would make sense to inform listeners of the complete connected change that was done over multiple refs in a single event. Basically, the event would not have

  public String getRefName()

but

  public Set<String> getRefNames()

And as discussed, we should stay backward compatible at least for a while by allowing to still use ref-updated either alone or at the same time as refs-updated.

On the other hand, users voiced concerns about big changes in existing behaviour during the user summit and I would include replacing the ref-updated event with a refs-updated event, even if gradually, into this category. So finding a different solution would certainly be preferable for a considerable fraction of Gerrit's user base.
 

Sven Selberg

unread,
Dec 10, 2021, 5:44:17 AM12/10/21
to Repo and Gerrit Discussion
I was talking about not doing the bundling in the replication plugin were we have little control which refs should be batched together, and must naively update meta-refs since we don't know whether they are updated or not.
I imagined that we have some type of control over this in BatchRefUpdate, so if a meta-ref is updated in the same batch as change-refs you add them to the same ref-updated event, if no meta-refs are updated none are added to the event.
 
 
or
2. To cater to the case where only the meta-ref is updated but not the patchset, we could add metaRefUpdate to ref-update event but also introduce a new type "meta-ref-update" for the "only meta-ref" case.
     That way existing consumers, who are already filtering for type "ref-update", wont have to deal with the "only meta-ref update" case. 

This would also require the adaptation of quite some event listeners. Also logically there should then be a meta-ref-update event, even if a change ref is updated at the same time, because maybe a listener is only interested in meta-refs. So we would fire additional events with duplicated data.

I'm not too worried about adapting internal event-listeners, I was more trying to protect those who listen to event-streams from stream-events, kafka, rabbitmq et.al.
Only internal (core+plugins) should be interested in meta-ref-updates and those are "easy" to adapt since we have builds and tests that break if we don't.
 
 
An additional benefit is that we could prioritize meta-ref-updates in replication so that f.i. ACL changes are more likely to be replicated before other other ref-updates.

We would rather have to prioritise the firing of the events, meta-ref before change-ref, since the replication plugin will collect refs for a push for a configured amount of time after the first ref-updated event. What happened in the issue we saw was, that on a busy project, if the ref-updated for the change ref was received first and the ref-updated event of the meta ref only later after the push request was sent out, they were not replicated at the same time. It might be a solution to order the event firing to fire ref-updated for the meta-ref first. I am not sure if that wouldn't cause different issues.
 
I still think it would make sense to inform listeners of the complete connected change that was done over multiple refs in a single event. Basically, the event would not have

I don't know how this could benefit any external listeners.
The way I see it we have two APIs, the external (currently JSON) and internal (dtos).

If my assumption is correct  and we don't have to cater to the external listeners, we could potentially use the current events but in the dtos add links to related events.
So the field "metaRefUpdates" is a list of references to other events that is never serialized (or if we introduce a UUID field for all events it might be).
The added complication is that we need to assure that the meta ref-update is fired after the "parent" ref-update, or have an optional "parent" or "triggeredBy" for linking the other way around.
(regardless of how the initial problem is solved it might not be a bad idea to group related events with some type of transaction id or similar. It would make the analysis of historical events much easier.)

We could potentially also solve this problem by switching to refs-updated internally but for outward facing events (stream-events and events-.* plugins) split them into ref-updated events for backwards compatibility.


  public String getRefName()

but

  public Set<String> getRefNames()

And as discussed, we should stay backward compatible at least for a while by allowing to still use ref-updated either alone or at the same time as refs-updated.

On the other hand, users voiced concerns about big changes in existing behaviour during the user summit and I would include replacing the ref-updated event with a refs-updated event, even if gradually, into this category. So finding a different solution would certainly be preferable for a considerable fraction of Gerrit's user base.

This is my main concern also, if possible keep backwards compatibility in outward facing APIs (such as REST, events).

Thomas Dräbing

unread,
Dec 16, 2021, 6:41:29 AM12/16/21
to Sven Selberg, Repo and Gerrit Discussion
If we would go with keeping the ref-updated event and not adding refs-updated, I would suggest to add a field `updatedInSameBatch` containing a list of all refs updated by the same BatchRefUpdate or an empty list, if it was a simple RefUpdate, similar to what you suggested. This would be a more general name and fit also other uses of BatchRefUpdate.
For the replication plugin this would still mean that in the case that the ref-updated events for the change ref and the meta ref are not processed by the same push task, that the respective refs would be added to two push tasks, but that should not be a huge issue. This is basically what Luca suggested earlier.
 
We could potentially also solve this problem by switching to refs-updated internally but for outward facing events (stream-events and events-.* plugins) split them into ref-updated events for backwards compatibility.

As I mentioned before, I would not replace ref-updated with refs-updated, but keep both and make it configurable to fire either or both of them. Thus, it would be backwards-compatible and listeners of both events could exist at the same time and would both be posted to the outward facing event streams. However, this of course adds complexity to managing a Gerrit server.
 

  public String getRefName()

but

  public Set<String> getRefNames()

And as discussed, we should stay backward compatible at least for a while by allowing to still use ref-updated either alone or at the same time as refs-updated.

On the other hand, users voiced concerns about big changes in existing behaviour during the user summit and I would include replacing the ref-updated event with a refs-updated event, even if gradually, into this category. So finding a different solution would certainly be preferable for a considerable fraction of Gerrit's user base.

This is my main concern also, if possible keep backwards compatibility in outward facing APIs (such as REST, events).

Of the two suggestions, adding an additional field to ref-updated is the less disruptive solution, but adding a refs-updated event in addition to ref-updated would more closely reflect how refs are actually updated.

I personally would prefer the solution to add a refs-updated event, but see valid arguments for the other solution as well. Let me summarise the solutions proposed here in a design document that can then be voted upon by the maintainers. Due to time constraints on my side, this will however likely only be ready next year.

 

Sven Selberg

unread,
Dec 16, 2021, 7:03:15 AM12/16/21
to Repo and Gerrit Discussion
My proposal is to have a refs-updated event internally (for internal and plugin event-listeners) but split this event into ref-updated events for external listeners (stream-events, events-rabbitmq (i.e. the plugin splits before publishing to event-bus), events-kafka(i.e. the plugin splits before publishing to event-bus))
 

 
 
Just a thought.
 
 

The drawback is that you may receive one event twice, which is a minor issue IMHO.

WDYT?

Luca.


-- 
-- 
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 on the web visit https://groups.google.com/d/msgid/repo-discuss/CAG7bb4AekueTeECXxD2ZQBB0LYXh9uab9SYEyXPnk_U6ARNLOg%40mail.gmail.com.


(i.e. the plugin splits before publishing to event-bus)

Thomas Dräbing

unread,
Jan 26, 2022, 8:32:31 AM1/26/22
to Sven Selberg, Repo and Gerrit Discussion
Sorry that I misunderstood you there. This is indeed the best solution IMO. I have pushed an implementation of that solution [1]. It would be great to get your opinion/review.

 
Reply all
Reply to author
Forward
0 new messages