On Thu, 03 Apr 2025 18:40:20 +0200, Remo Senekowitsch wrote: > On Thu Apr 3, 2025 at 5:39 PM CEST, Elijah Newren wrote: >> cherry-pick & rebase preserve author name, email & time, while creating a >> new committer name, email, & time. To me, the change-id is about the >> authorship, and since these commands already preserve authorship, it'd seem >> weird to me to have cherry-pick not preserve the change-id by default. > I'd say Jujutsu, Gerrit and GitButler think of a change-id as associated with > a unit of review. > > [...] > > Cherry-picking on the other hand often represents a separate unit of review. > That review may revolve around whether it makes sense to backport a bugfix at > all or any additional changes that may have been necessary to make the bugfix > work in the different, older codebase. > > As mentioned above, there's also the issue that preserving the change-id on > cherry-pick likely results in duplicates. For Jujutsu, it would be nice it > this was avoided. But it's not infeasible to deal with that either. > > For Gerrit, it would be important to be able to track a change across > cherry-picks somehow, since that is a feature they already have. If Git > decides to preserve the change-id on cherry-pick, there's no problem for > Gerrit. Alternatives include storing a separate cherry-picked-from header or > enabling the -x flag on cherry-pick by default. I agree, and propose this concrete behavior: - git cherry-pick generates a fresh `change-id`, and places the old change-id in a `cherry-picked-change` header - git cherry-pick preserves the old `change-id` if passed the new `--preserve-change-id` flag - git rebase passes the `--preserve-change-id` flag on 'pick' actions, unless passed the new `--no-preserve-change-id` flag - git rebase uses the earlier commit's change-id on 'fixup' actions - git rebase prints the change-ids into the COMMIT_MSG on 'squash' actions, and tries to read the user's choice of which to use, defaulting to the earlier commit if both or none are present - git rebase creates a new change-id on 'merge' actions - git rebase needs no special behavior specified for 'edit', 'exec', 'break', 'drop', 'label', 'reset', 'update-ref'
