On Thu, Apr 03, 2025 at 08:39:31AM -0700, Elijah Newren wrote: > On Wed, Apr 2, 2025 at 11:48 AM Martin von Zweigbergk > > 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? I agree that `git rebase main <change ID>; git switch <change ID>` is not a good UI, and I wouldn't want it even though I want change IDs. Change IDs are documentary, and they help people understand that various commits are just edits/rewrites of the same original commit. > 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? Worse: since there can be many commits with the same change ID they can't be used as refs because Git can't possibly be expected to find _the one_ you really intend -- how could it? I suppose Git could let you pick from a list, but that's not likely going to have enough context. Maybe Git could give you a list of named branches in which it found some change ID's commits to pick one branch from, or maybe one could `git cherry-pick --from $some_branch $cid` and have Git find the commit(s) on `$some_branch` that match change ID `$cid`. Also, maybe commits need to support multiple change IDs. For example, one might want one change ID for a set of commits (eg implementing a feature), and each commit in the set having a second and more unique change ID for just that commit (and all edits/rewrites of it). > Yaay, I always hated it as a trailer. More headers is better. > 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. +1. Besides, rebase is just a a bunch of cherry-picks, so cherry-pick is the fundamental operation here. If rebase is to preserver change-id then so is cherry-pick. Nico --
