Rundown of working against upstream repo, with Change-Id's stripped?

[Kaz Kylheku]

I've researched this topic a bit and found some past discussions, about it.

The situation is: using Gerrit for producing local patches that are rebased against a moving upstream, on a daily bases.

I read that common practice involves abandoning the local review once it has been upstreamed, scrubbed of its Change-Id and pulled down again.

The problem is that the change has to be submitted locally; the local team needs the change to be merged so that everyone picks it up. It could be weeks or months before it is upstreamed, and in fact some changes aren never upstreamed.

What happens to a Submitted Gerrit item when the submitted patchset's commit is reflected back from upstream without its Change-Id?

[Sven Selberg]

In the process of removing the change-id you create a new commit and without the change-id Gerrit won't recognize that the new commit is a version of the existing change.
I don't think I understand the workflow you are describing as it doesn't make sense to me in git-context.
Since you are working with change-ids locally and without change-ids upstream they are two different git DAGs.
If you only care about the working tree in git you could keep a "local" branch were you create changes and merge them at your own pace while pulling upstream into "upstream" branch that you regularly merge into "local" (but that seems like a lot of work.

Don't know if the situation would be improved with the ideas from jujutsu about having the change-id as a commit-header instead of as a footer?
Perhaps upstream wouldn't notice the change-id header and Gerrit would recognize the commit as part of an existing change.
Alas if you merged the change locally and afterwards try to import the upstream version of the commit to the same branch with the change-id header intact Gerrit would refuse the push if it recognizes a commit as belonging to an already merged change on that branch.

[Nasser Grainawi]

On Mon, Dec 15, 2025 at 12:39 AM Sven Selberg <sven.s...@axis.com> wrote:

On Friday, December 12, 2025 at 6:34:20 PM UTC+1 Kaz Kylheku wrote:

I've researched this topic a bit and found some past discussions, about it.

The situation is: using Gerrit for producing local patches that are rebased against a moving upstream, on a daily bases.

I read that common practice involves abandoning the local review once it has been upstreamed, scrubbed of its Change-Id and pulled down again.

The problem is that the change has to be submitted locally; the local team needs the change to be merged so that everyone picks it up. It could be weeks or months before it is upstreamed, and in fact some changes aren never upstreamed.

What happens to a Submitted Gerrit item when the submitted patchset's commit is reflected back from upstream without its Change-Id?

In the process of removing the change-id you create a new commit and without the change-id Gerrit won't recognize that the new commit is a version of the existing change.
I don't think I understand the workflow you are describing as it doesn't make sense to me in git-context.

I think this is describing something like a team that is maintaining branches in Gerrit based on an upstream not using Gerrit (for example, the Linux kernel) and both sending their patches to that upstream (in the kernel case, via the mailing list) and using Gerrit to review/submit their commits to a "downstream" branch. The upstream mailing list doesn't allow/accept Change-Id footers in commit messages, so there's no way to keep that association maintained between the downstream branch commits and the (hopefully) eventually merged upstream commits.

 

Since you are working with change-ids locally and without change-ids upstream they are two different git DAGs.
If you only care about the working tree in git you could keep a "local" branch were you create changes and merge them at your own pace while pulling upstream into "upstream" branch that you regularly merge into "local" (but that seems like a lot of work.

Don't know if the situation would be improved with the ideas from jujutsu about having the change-id as a commit-header instead of as a footer?

If the upstream is using tools that would maintain the change-id commit header, yes, this would solve it with the addition of Gerrit support for reading that custom header. I do think this will be the eventual future solution, but... For now, there's not a lot of tooling that will maintain that extra commit headers (for example, 'git am' and 'git rebase' don't), so most upstreams will end up with commits without the custom change-id header. There was a big thread on the git mailing list and then a follow up discussion during Git Merge earlier this year discussing how to make git work better with Change-Ids. There's some openness to improvements within the git community, but also reluctance to do a lot in support of something not used by git itself. If there end up being some use cases in git that use a change-id, that would certainly help push the effort along.

 

Perhaps upstream wouldn't notice the change-id header and Gerrit would recognize the commit as part of an existing change.
Alas if you merged the change locally and afterwards try to import the upstream version of the commit to the same branch with the change-id header intact Gerrit would refuse the push if it recognizes a commit as belonging to an already merged change on that branch.

--
--
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/089cc050-5b3a-423e-9391-57946ed01b52n%40googlegroups.com.

[Sven Selberg]

On Monday, December 15, 2025 at 7:49:23 PM UTC+1 Nasser Grainawi wrote:

On Mon, Dec 15, 2025 at 12:39 AM Sven Selberg <sven.s...@axis.com> wrote:

On Friday, December 12, 2025 at 6:34:20 PM UTC+1 Kaz Kylheku wrote:

I've researched this topic a bit and found some past discussions, about it.

The situation is: using Gerrit for producing local patches that are rebased against a moving upstream, on a daily bases.

I read that common practice involves abandoning the local review once it has been upstreamed, scrubbed of its Change-Id and pulled down again.

The problem is that the change has to be submitted locally; the local team needs the change to be merged so that everyone picks it up. It could be weeks or months before it is upstreamed, and in fact some changes aren never upstreamed.

What happens to a Submitted Gerrit item when the submitted patchset's commit is reflected back from upstream without its Change-Id?

In the process of removing the change-id you create a new commit and without the change-id Gerrit won't recognize that the new commit is a version of the existing change.
I don't think I understand the workflow you are describing as it doesn't make sense to me in git-context.

I think this is describing something like a team that is maintaining branches in Gerrit based on an upstream not using Gerrit (for example, the Linux kernel) and both sending their patches to that upstream (in the kernel case, via the mailing list) and using Gerrit to review/submit their commits to a "downstream" branch. The upstream mailing list doesn't allow/accept Change-Id footers in commit messages, so there's no way to keep that association maintained between the downstream branch commits and the (hopefully) eventually merged upstream commits.

Yes, that part is clear, it was the "merge commits "locally" before they are merged upstream and merge upstream back locally when they are merged upstream" part I couldn't wrap my head around.

 

 

Since you are working with change-ids locally and without change-ids upstream they are two different git DAGs.
If you only care about the working tree in git you could keep a "local" branch were you create changes and merge them at your own pace while pulling upstream into "upstream" branch that you regularly merge into "local" (but that seems like a lot of work.

Don't know if the situation would be improved with the ideas from jujutsu about having the change-id as a commit-header instead of as a footer?

If the upstream is using tools that would maintain the change-id commit header, yes, this would solve it with the addition of Gerrit support for reading that custom header. I do think this will be the eventual future solution, but... For now, there's not a lot of tooling that will maintain that extra commit headers (for example, 'git am' and 'git rebase' don't), so most upstreams will end up with commits without the custom change-id header. There was a big thread on the git mailing list and then a follow up discussion during Git Merge earlier this year discussing how to make git work better with Change-Ids. There's some openness to improvements within the git community, but also reluctance to do a lot in support of something not used by git itself. If there end up being some use cases in git that use a change-id, that would certainly help push the effort along.

I also think it would require the change-id-header to be supported by git for it to be a viable "option".

[Kaz Kylheku]

The process of rebasing the commit to get it to merge upstream creates a new commit also.

Adjusting commit messages is par for the course in open source upstreaming; even if they preserved the Change-Id, they might change other details in the commit.

Git itself is robust in this way. If you have a local commit which is accepted upstream in a slightly modified form, and you pull that down and rebase your local repo over it, your local commit is recognized as obsolete and disappears in the rebase.

I'm aware about the discussions revolving around gerrit and jujutsu; the proposal for Gerrit to adopt the change-id header, which is also being considered by git (required to make it really work).

I'm asking about a workflow without all those proposals implemented, which I can follow today.

Basically, how does Gerrit react to having commits rebased on an upstream, whereby some of them may disappear due to having been merged upstream.  Does Gerrit notice that a certain commit that was merged, with a Change-Id, is suddenly "missing"? (It is still there, in an upstreamed form.).  Does the corresponding Gerrit item revert from Submitted to Open?

[Kaz Kylheku]

I don't care about maintaining the headers. All I want to know is, does Gerrit require special handling when the trunk is rebased to new upstream baselines behind its back, so to speak? And what happens when commits appear upstream which originated in that Gerrit as change, but now come down in an upstreamed form without the Change-Id? Does Gerrit react to any of these situations in ways that require special handling?

The lifecycle of a change initiated from our side is like this:

1. We create the change and submit to the Gerrit review system.
2. The approved patch set of the change is submitted locally.
3. Change is rebased numerous times "behind Gerrit's back" as we integrate with upstream work. We rewrite local history when we do these rebases.
4. Upstream accepts the change.

5. The next rebase to upstream now brings the change down from upstream; the original local one is obsolete and disappears; is is no longer part of the local patch set that is being continuously rebased.

This is all very clear from a pure Git perspective; I can do most of it with my eyes closed. The only question mark is Gerrit's behavior.