On Thu Apr 3, 2025 at 5:39 PM CEST, Elijah Newren wrote: > On Wed, Apr 2, 2025 at 11:48 AM Martin von Zweigbergk > <martinvonz@xxxxxxxxxx> wrote: >> >> There are many benefits to having a change id even if it's just >> local. I mentioned some in my email to this mailing list in [1]. >> 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. > > But <change ID> isn't unique, right? The whole point of having the > change ID is to preserve it despite edits (e.g. rebase, commit > --amend, cherry-pick), meaning that you end up with multiple commits > with the same <change ID>. > > Why would this work? > > And if it does work, isn't it expensive since you'd need to walk > history to find it? Or do you keep an extra lookup table on the side > somewhere? For rebase and commit --amend, the way Jujutsu deals with those is that all descendants are immediately rebased on top of the new commit, and refs to those descendants are updated as well. That means, the old version of the patch with the same change-id becomes unreachable. So, at least most of the time, the change-id is indeed unique. This doesn't work for cherry-pick, more on that below. Some of these features are not in Git yet, at least not to my knowledge. That means getting the full benefit of change-ids with Git itself would indeed require some more work. I know of rebase.updateRefs and rebase.rebaseMerges, which move the Git experience closer to Jujutsu, but don't go all the way. AFAIK it's not possible with Git to automatically rebase --update-refs all descendants of a commit that is amended or rebased. Jujutsu does keep a separate index of change-ids, yes. >> There is a design doc [2] about the impact on Gerrit and how to >> handle various cases where the client doesn't understand the >> `change-id` header. That also includes some discussion about >> whether cherry-picking should preserve the change id or create a >> new one. I think there is a lot of value in having a >> standardized header regardless of what we decide about >> cherry-picks. > > 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. (Although it will naturally support reviewing sets of patches as well.) Usually only one person will push commits with the same change-id, just like people don't usually force-push over each others branches. But that's mostly about avoiding logistical problems. When an employee leaves a company or is on vacation, it can be perfectly reasonable for someone else to take over their work. In that case, it would be appropriate to preserve the change-id, even though authorship has changed, because the history of code review on that patch should stay associated with the new version. 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. Remo
