Martin von Zweigbergk <martinvonz@xxxxxxxxxx> writes: > For example, it enables > `git rebase main <change ID>; git switch <change ID>` without > requiring the user to look up the hash of the rewritten commit. I do not quite see why this can be listed even as an advantage, unless you are going to allow end users to name the changes, instead of using auto-generated impossible-to-remember hexadecimal string (perhaps prefixed with a single "I" or something). > If the change id also transferred between repos and preserved by > a forge (such as Gerrit), it enables the change id to be used to > identify a code review. People often talk about rebasing and rewriting in the context of discussing "change IDs", and for 80% of the use cases where a simple single-commit topic is involved, it would perfectly work fine. After making a new commit C0 on top of 'main', updating 'main' with others' changes, and then rebasing that C0 on top of updated 'main' to produce C1, you would expect that C0 and C1 are moral equivalents so it is natural that you wish there is a name to give to these moral equivalents. But stepping back a bit, if they are not just moral equivalents but record identical changes that are so same that an earlier review of C0 makes it unnecessary to review C1, why are you even rebasing in the first place? Just merging C0 to the updated 'main' would retain the earlier review made on C0 and things should merge just fine. 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? 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.
