How to reconcile gerrit with upstream merges that strip change-id? Maybe using git cherry / patch-id?

138 views
Skip to first unread message

Pat Maddox

unread,
Oct 19, 2025, 7:05:40 AMOct 19
to repo-d...@googlegroups.com
Hi there, I've been using gerrit for my personal code review before submitting patches to upstream projects, and it's excellent. I wish I had come across this tool years ago.

The upstream projects do not accept the change-id trailer. I'm able to strip it out with scripts before submitting, so that's not an issue. I'm finding that when I rebase my local branch off of upstream, jujutsu does what it's supposed to - removes all of the empty commits that are now present in the branch - but pushing the newly updated branch to gerrit has no effect on the changes. If the commits had the change-id trailer, it would mark them as merged, but it doesn't.

Right now I manually go through each of the commits and abandon them with a comment "merged upstream." However I'm hoping there's a way that gerrit can recognize the commits, and mark them as merged.

Git has the notion of "patch id" which hashes the diff content, irrespective of commit metadata including parent. This is what `git cherry` uses to determine if a commit is present in multiple branches. `git show <commit> | git patch-id` will calculate this.

Does Gerrit have a way to detect that a change has been merged upstream, even though the change-id has been removed?

Thanks,
Pat

Sven Selberg

unread,
Oct 20, 2025, 2:11:56 AMOct 20
to Repo and Gerrit Discussion
No, the Change-Id footer is the way that Gerrit determines if a commit is part of a change or not (combined with $PROJECT and $BRANCH).
The patch-id identification wouldn't work for Gerrit as two patchsets may contain completely different diffs.

BR
Sven
 


Thanks,
Pat

mfick

unread,
Oct 22, 2025, 11:17:08 AMOct 22
to Repo and Gerrit Discussion
Sven, git patch-id != Gerrit patchId, they are two different concepts. The git patch-id represents the diff.

Although Gerrit only uses the Change-Id currently for this, I think the project would likely be open to changes which would index the git patch-id to do what you propose. It would mean potentially doing a lot more work on pushes, which could be expensive, so care would need to be taken here (make it configurable/optional...),

-Martin


Nasser Grainawi

unread,
Oct 22, 2025, 11:52:04 AMOct 22
to mfick, Repo and Gerrit Discussion
On Wed, Oct 22, 2025 at 9:17 AM 'mfick' via Repo and Gerrit Discussion <repo-d...@googlegroups.com> wrote:
On Monday, October 20, 2025 at 8:11:56 AM UTC+2 Sven Selberg wrote:
On Sunday, October 19, 2025 at 1:05:40 PM UTC+2 Pat Maddox wrote:
Hi there, I've been using gerrit for my personal code review before submitting patches to upstream projects, and it's excellent. I wish I had come across this tool years ago.

The upstream projects do not accept the change-id trailer. I'm able to strip it out with scripts before submitting, so that's not an issue. I'm finding that when I rebase my local branch off of upstream, jujutsu does what it's supposed to - removes all of the empty commits that are now present in the branch - but pushing the newly updated branch to gerrit has no effect on the changes. If the commits had the change-id trailer, it would mark them as merged, but it doesn't.

What you're missing is the implementation of this accepted Gerrit design to support Jujutsu's (and GitButler's) way of using a change-id in the commit object header.

When that's added to Gerrit (no timeline AFAIK, not sure if anyone has started work on it yet), you won't need the trailer line at all and the change-id from the commit object header will be used instead. There was also discussion at Git Merge around git itself having more direct support for change-ids in commit object headers (not removing them during rebase, etc).

Nasser
 


Right now I manually go through each of the commits and abandon them with a comment "merged upstream." However I'm hoping there's a way that gerrit can recognize the commits, and mark them as merged.

Git has the notion of "patch id" which hashes the diff content, irrespective of commit metadata including parent. This is what `git cherry` uses to determine if a commit is present in multiple branches. `git show <commit> | git patch-id` will calculate this.

Does Gerrit have a way to detect that a change has been merged upstream, even though the change-id has been removed?

No, the Change-Id footer is the way that Gerrit determines if a commit is part of a change or not (combined with $PROJECT and $BRANCH).
The patch-id identification wouldn't work for Gerrit as two patchsets may contain completely different diffs.

Sven, git patch-id != Gerrit patchId, they are two different concepts. The git patch-id represents the diff.

Although Gerrit only uses the Change-Id currently for this, I think the project would likely be open to changes which would index the git patch-id to do what you propose. It would mean potentially doing a lot more work on pushes, which could be expensive, so care would need to be taken here (make it configurable/optional...),

-Martin


--
--
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/33d5d344-a837-4ec7-8241-c24db395fa9dn%40googlegroups.com.

Pat Maddox

unread,
Oct 22, 2025, 1:44:40 PMOct 22
to Repo and Gerrit Discussion
Thanks for the replies everyone. I don't use google groups much, apparently I didn't have the notifications configured correctly.

Yes it seems like an option to "merge matching patch IDs" would be worthwhile. Basically turning "merge = matches?(change-id)" to "merge = matches?(change-id) or matches?(patch-id)". Then when new changes get uploaded, gerrit would calculate and store the patch id. Same for new commits pushed. I am very interested in this behavior, so I'll see if I can take a crack at it.

Pat

Pat Maddox

unread,
Oct 22, 2025, 1:44:47 PMOct 22
to Repo and Gerrit Discussion
On Wednesday, October 22, 2025 at 8:52:04 AM UTC-7 Nasser Grainawi wrote:
On Wed, Oct 22, 2025 at 9:17 AM 'mfick' via Repo and Gerrit Discussion <repo-d...@googlegroups.com> wrote:
On Monday, October 20, 2025 at 8:11:56 AM UTC+2 Sven Selberg wrote:
On Sunday, October 19, 2025 at 1:05:40 PM UTC+2 Pat Maddox wrote:
Hi there, I've been using gerrit for my personal code review before submitting patches to upstream projects, and it's excellent. I wish I had come across this tool years ago.

The upstream projects do not accept the change-id trailer. I'm able to strip it out with scripts before submitting, so that's not an issue. I'm finding that when I rebase my local branch off of upstream, jujutsu does what it's supposed to - removes all of the empty commits that are now present in the branch - but pushing the newly updated branch to gerrit has no effect on the changes. If the commits had the change-id trailer, it would mark them as merged, but it doesn't.

What you're missing is the implementation of this accepted Gerrit design to support Jujutsu's (and GitButler's) way of using a change-id in the commit object header.

When that's added to Gerrit (no timeline AFAIK, not sure if anyone has started work on it yet), you won't need the trailer line at all and the change-id from the commit object header will be used instead. There was also discussion at Git Merge around git itself having more direct support for change-ids in commit object headers (not removing them during rebase, etc).

Nasser

Thanks for that. I read through it, and it's not clear to me that it addresses the scenario I'm talking about. Here's a more detailed example:

1. I write a patch for freebsd-ports and upload a change to gerrit.
2. I use `git format-patch` to send the patch upstream (stripping out change-id trailer)
3. A committer reviews and commits it
4. `git pull --rebase` gets the new commit 
5. I push to gerrit

What I'd _like_ to happen is for gerrit to see that the change is now merged. The diff is exactly the same as what I uploaded - it's simply the metadata (committer name / email, sometimes commit message) that is different from what gerrit knows about. Same diff, different commit.

The review looks like it would require jujutsu. The workflow that I shared above is pretty common in open source, and should not depend on jujutsu at all. That design doc appears to be focused entirely on tracking the change id - when what I'm pointing out is that git already provides enough info to determine that a change has been merged.

From what I can tell, that design doc requires:

1. I be using jujutsu
2. I git fetch on the same machine I used to create the patch
3. jujutsu notices that the upstream branch has the same change, and (I guess) migrates the change id from the original commit to the new one?
4. I be the person to push the updated branch to gerrit

In reality, it could work more like:

1. I submit a change
2. Someone else commits it
3. A third person, using git, pushes the updated main branch to a shared gerrit instance

I believe git provides all the info needed to track that already, and that it would be useful if gerrit did so.

Pat

Nasser Grainawi

unread,
Oct 22, 2025, 2:05:48 PMOct 22
to Pat Maddox, Repo and Gerrit Discussion
On Wed, Oct 22, 2025 at 11:44 AM Pat Maddox <p...@patmaddox.com> wrote:
On Wednesday, October 22, 2025 at 8:52:04 AM UTC-7 Nasser Grainawi wrote:
On Wed, Oct 22, 2025 at 9:17 AM 'mfick' via Repo and Gerrit Discussion <repo-d...@googlegroups.com> wrote:
On Monday, October 20, 2025 at 8:11:56 AM UTC+2 Sven Selberg wrote:
On Sunday, October 19, 2025 at 1:05:40 PM UTC+2 Pat Maddox wrote:
Hi there, I've been using gerrit for my personal code review before submitting patches to upstream projects, and it's excellent. I wish I had come across this tool years ago.

The upstream projects do not accept the change-id trailer. I'm able to strip it out with scripts before submitting, so that's not an issue. I'm finding that when I rebase my local branch off of upstream, jujutsu does what it's supposed to - removes all of the empty commits that are now present in the branch - but pushing the newly updated branch to gerrit has no effect on the changes. If the commits had the change-id trailer, it would mark them as merged, but it doesn't.

What you're missing is the implementation of this accepted Gerrit design to support Jujutsu's (and GitButler's) way of using a change-id in the commit object header.

When that's added to Gerrit (no timeline AFAIK, not sure if anyone has started work on it yet), you won't need the trailer line at all and the change-id from the commit object header will be used instead. There was also discussion at Git Merge around git itself having more direct support for change-ids in commit object headers (not removing them during rebase, etc).

Nasser

Thanks for that. I read through it, and it's not clear to me that it addresses the scenario I'm talking about. Here's a more detailed example:

1. I write a patch for freebsd-ports and upload a change to gerrit.
2. I use `git format-patch` to send the patch upstream (stripping out change-id trailer)
3. A committer reviews and commits it
4. `git pull --rebase` gets the new commit 
5. I push to gerrit

What I'd _like_ to happen is for gerrit to see that the change is now merged. The diff is exactly the same as what I uploaded - it's simply the metadata (committer name / email, sometimes commit message) that is different from what gerrit knows about. Same diff, different commit.

Gotcha! Yes, the Jujutsu design on its own wouldn't do this. The future potential of git native support for change-ids *could*. What I think that would look like is:
1. In your step 2, the change-id in the commit object header is converted into an email header by `git format-patch` or `git send-email` (like what this git patch proposes)
2. In your step 3, when the committer applies the patch to their repo, `git am` would read the email header and include it in the new commit object (like what this git patch proposes)
3. In your step 5, just like what you want, when you push to Gerrit, it finds the matching change-id in the commit object, adds a new patchset to your change for that upstream commit, and closes the change (just like it would currently do if the Change-Id trailer was present in the upstream commit).

That doesn't require using jujutsu and should "just work" with many existing open source workflows. It does require getting those upstream patches merged into git and (assuming it's not default behavior) getting users to enable the correct configs to propagate change-ids like this. And of course it still needs that Gerrit feature to support change-ids in commit object headers.
 

The review looks like it would require jujutsu. The workflow that I shared above is pretty common in open source, and should not depend on jujutsu at all. That design doc appears to be focused entirely on tracking the change id - when what I'm pointing out is that git already provides enough info to determine that a change has been merged.

I do agree that Gerrit could try to do something beyond looking for a matching Change-Id when trying to see if pushed commits should update an existing change. I don't know if there's an existing plugin extension point (maybe one of these ReceivePack ones?) that would let someone add this outside of core Gerrit, but at least that extension does seem like a thing we would want in core Gerrit.
 

From what I can tell, that design doc requires:

1. I be using jujutsu
2. I git fetch on the same machine I used to create the patch
3. jujutsu notices that the upstream branch has the same change, and (I guess) migrates the change id from the original commit to the new one?
4. I be the person to push the updated branch to gerrit

In reality, it could work more like:

1. I submit a change
2. Someone else commits it
3. A third person, using git, pushes the updated main branch to a shared gerrit instance

I believe git provides all the info needed to track that already, and that it would be useful if gerrit did so.

Pat

--
--
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.

Sven Selberg

unread,
Oct 23, 2025, 2:11:37 AMOct 23
to Repo and Gerrit Discussion
On Wednesday, October 22, 2025 at 5:17:08 PM UTC+2 mfick wrote:
On Monday, October 20, 2025 at 8:11:56 AM UTC+2 Sven Selberg wrote:
On Sunday, October 19, 2025 at 1:05:40 PM UTC+2 Pat Maddox wrote:
Hi there, I've been using gerrit for my personal code review before submitting patches to upstream projects, and it's excellent. I wish I had come across this tool years ago.

The upstream projects do not accept the change-id trailer. I'm able to strip it out with scripts before submitting, so that's not an issue. I'm finding that when I rebase my local branch off of upstream, jujutsu does what it's supposed to - removes all of the empty commits that are now present in the branch - but pushing the newly updated branch to gerrit has no effect on the changes. If the commits had the change-id trailer, it would mark them as merged, but it doesn't.

Right now I manually go through each of the commits and abandon them with a comment "merged upstream." However I'm hoping there's a way that gerrit can recognize the commits, and mark them as merged.

Git has the notion of "patch id" which hashes the diff content, irrespective of commit metadata including parent. This is what `git cherry` uses to determine if a commit is present in multiple branches. `git show <commit> | git patch-id` will calculate this.

Does Gerrit have a way to detect that a change has been merged upstream, even though the change-id has been removed?

No, the Change-Id footer is the way that Gerrit determines if a commit is part of a change or not (combined with $PROJECT and $BRANCH).
The patch-id identification wouldn't work for Gerrit as two patchsets may contain completely different diffs.

Sven, git patch-id != Gerrit patchId, they are two different concepts. The git patch-id represents the diff.

Gerrit does not have a patch-id concept Martin, it has a patchset-id which is a combined key of change-id (which I mention) and patch-set-number (which I never mention) :-)
 

Although Gerrit only uses the Change-Id currently for this, I think the project would likely be open to changes which would index the git patch-id to do what you propose. It would mean potentially doing a lot more work on pushes, which could be expensive, so care would need to be taken here (make it configurable/optional...),

I wouldn't be in favor of such an effort. Instinctively it sounds like a complex and error-prone feature that would make debugging of issues very difficult.
Implementing the jujutsu "change-id header" (that Nasser brought up) seems to me like the proper way forward to solve this and similar issues (with the added benefit that it might pave the way for a git-native "change" concept).


-Martin


Luca Milanesio

unread,
Oct 23, 2025, 3:13:54 AMOct 23
to Repo and Gerrit Discussion, Luca Milanesio
+1, it would be nice if also GitButler could agree on the same header, as its workflow is very nicely integrated with Gerrit [1].

Luca.


Matthias Sohn

unread,
Oct 23, 2025, 3:19:05 AMOct 23
to Luca Milanesio, Repo and Gerrit Discussion

--
--
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.

mfick

unread,
Oct 23, 2025, 1:09:36 PMOct 23
to Repo and Gerrit Discussion
On Thursday, October 23, 2025 at 9:19:05 AM UTC+2 Matthias Sohn wrote:
+1, it would be nice if also GitButler could agree on the same header, as its workflow is very nicely integrated with Gerrit [1].

I believe this was already done.
The primary links in that doc results in "NOT FOUND" for me,

-Martin
 

Nasser Grainawi

unread,
Oct 23, 2025, 2:02:56 PMOct 23
to mfick, Repo and Gerrit Discussion
It should be the same as the one I shared earlier. I linked directly to the solution page, but this is the index page: https://www.gerritcodereview.com/design-docs/support-jujutsu.html
 

-Martin
 

--
--
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.

Luca Milanesio

unread,
Oct 23, 2025, 2:11:57 PMOct 23
to Repo and Gerrit Discussion, Luca Milanesio

On 23 Oct 2025, at 18:09, 'mfick' via Repo and Gerrit Discussion <repo-d...@googlegroups.com> wrote:

On Thursday, October 23, 2025 at 9:19:05 AM UTC+2 Matthias Sohn wrote:
+1, it would be nice if also GitButler could agree on the same header, as its workflow is very nicely integrated with Gerrit [1].

I believe this was already done.

I am just about to publish the “Q&A with the maintainers” recording and Patrick mentioned that:
“Junio is against doing anything in Git until GitButler, JJ and Gerrit agree on a common semantics on the Change-ID”

So I believe we’ve got some work to do, not done yet.

Luca.

 

The primary links in that doc results in "NOT FOUND" for me,

-Martin
 

--
--
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,
Oct 23, 2025, 4:55:01 PMOct 23
to mfick, Repo and Gerrit Discussion
you are right, same here, seems the links rendered on gerrit-review are broken
 

-Martin
 

--
--
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.

Pat Maddox

unread,
Oct 24, 2025, 5:55:13 PMOct 24
to Nasser Grainawi, Repo and Gerrit Discussion
On Wed, Oct 22, 2025, at 11:05 AM, Nasser Grainawi wrote:
> On Wed, Oct 22, 2025 at 11:44 AM Pat Maddox <p...@patmaddox.com> wrote:
>> On Wednesday, October 22, 2025 at 8:52:04 AM UTC-7 Nasser Grainawi wrote:
>>> On Wed, Oct 22, 2025 at 9:17 AM 'mfick' via Repo and Gerrit Discussion <repo-d...@googlegroups.com> wrote:
>>>> On Monday, October 20, 2025 at 8:11:56 AM UTC+2 Sven Selberg wrote:
>>>>> On Sunday, October 19, 2025 at 1:05:40 PM UTC+2 Pat Maddox wrote:
>>>>>> Hi there, I've been using gerrit for my personal code review before submitting patches to upstream projects, and it's excellent. I wish I had come across this tool years ago.
>>>>>>
>>>>>> The upstream projects do not accept the change-id trailer. I'm able to strip it out with scripts before submitting, so that's not an issue. I'm finding that when I rebase my local branch off of upstream, jujutsu does what it's supposed to - removes all of the empty commits that are now present in the branch - but pushing the newly updated branch to gerrit has no effect on the changes. If the commits had the change-id trailer, it would mark them as merged, but it doesn't.
>>>
>>> What you're missing is the implementation of this accepted Gerrit design <https://www.gerritcodereview.com/design-docs/support-jujutsu-solution.html> to support Jujutsu's (and GitButler's) way of using a change-id in the commit object header.
>>>
>>> When that's added to Gerrit (no timeline AFAIK, not sure if anyone has started work on it yet), you won't need the trailer line at all and the change-id from the commit object header will be used instead. There was also discussion <https://lore.kernel.org/git/aOQWWkj%2Fq7G...@nand.local/> at Git Merge around git itself having more direct support for change-ids in commit object headers (not removing them during rebase, etc).
>>>
>>> Nasser
>>
>> Thanks for that. I read through it, and it's not clear to me that it addresses the scenario I'm talking about. Here's a more detailed example:
>>
>> 1. I write a patch for freebsd-ports and upload a change to gerrit.
>> 2. I use `git format-patch` to send the patch upstream (stripping out change-id trailer)
>> 3. A committer reviews and commits it
>> 4. `git pull --rebase` gets the new commit
>> 5. I push to gerrit
>>
>> What I'd _like_ to happen is for gerrit to see that the change is now merged. The diff is exactly the same as what I uploaded - it's simply the metadata (committer name / email, sometimes commit message) that is different from what gerrit knows about. Same diff, different commit.
>
> Gotcha! Yes, the Jujutsu design on its own wouldn't do this. The future
> potential of git native support for change-ids *could*. What I think
> that would look like is:
> 1. In your step 2, the change-id in the commit object header is
> converted into an email header by `git format-patch` or `git
> send-email` (like what this git patch proposes
> <https://lore.kernel.org/git/2025070311350...@ddevault.org/>)

Thanks for sharing that discussion. If I'm reading right, this header is part of the commit itself. So this also supports another common open source workflow: push a branch and open a pull request. Correct?

Pat

Nasser Grainawi

unread,
Oct 27, 2025, 4:21:50 PMOct 27
to Pat Maddox, Repo and Gerrit Discussion
Yes, exactly. And so long as all the tools involved in your workflow (GitHub, GitLab, Gerrit, GitButler, Jujutsu, git, etc) agree to persist that header when doing things like 'rebase' or 'cherry-pick', the header should follow along for any "transformations".
 

Pat
Reply all
Reply to author
Forward
0 new messages