On Mon, Apr 07, 2025 at 08:59:56PM +0000, Junio C Hamano wrote: > I have more problems with the remaining 20% use case, where you need > to deal with multiple commits. > > Perhaps your initial changeset is a single commit C0 that is so > large and does too many things at once, and reviewers would > naturally advise you to split things up. You'll come up with a > series of commits, C1_0 and C1_1. The net effect of applying these > two patches may be the same as applying the original C0, but each of > them is more cleanly separated to address one issue at a time, and > the explanation given in the proposed log message more clearly > describes the issue each of them addresses. Now you gave a change ID > to C0, and want to somehow relate C1_0 and C1_1 to the original C0. > Which one gets the same change ID? Earlier one? The last one? > Both gets the same change ID? > > Or your initial changeset is a two-commit series, C0_0 and C0_1, but > reviewers find that each one of them alone is not complete, and > because the issue addressed by these two is small and isolated > enough, you are advised to make them into a single commit C1. Did > you start with two change IDs for these two original commits? If > so, whose change ID the updated commit C1 inherit? Or does C1 have > two change IDs now? Or did you start with a single change ID > assigned to both of these two original commits? This is why I suggested earlier that there need to be multiple change IDs, not just one. Perhaps one is a "code review ID" and another is a "commit change ID". The code review ID would let you link together all commits that were reviewed together, so if you have to split or squash commits they would all still have that one code review ID. The commit change ID would be shared by all sufficiently-similar versions of a commit. If a commit is dropped or split or squashed then its commit ID might get dropped too, but the code review ID would stay the same. I think that a code review ID is a lot saner to use as a ref, as in OP's `git switch ...` example. Though one might still want symbolic tag-like names for individual commits in a set of related commits (e.g., for forward- and back-ports), though I'm inclined to say that's not needed. > Quite frankly, I think the concept of "change ID" is nice but it is > not mechanically trustable. Recording them in the trailers is fine, > but I somehow feel that they have a clear-cut semantics everybody > can agree on to deserve to be in the header part of commit objects. I don't think they need to have such extremely detailed semantics in order to be able to get a header. The semantics will ultimately be somewhat project-defined, typically something like "during code review you can use these to related newer updates to an MR/PR/CR to older versions" and "once integrated you can use these to find the approved code review as follows [details]". The [details] (probably a URI template) for finding concluded CRs might vary. The CR tool might vary. The construction of the change IDs might vary. The intent might not vary at all. Nico --
