On Thu Apr 3, 2025 at 8:10 PM CEST, Nico Williams wrote: > On Thu, Apr 03, 2025 at 08:39:31AM -0700, Elijah Newren wrote: > 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). Semantically grouping a set of commits is an intersting idea, but not really related to the proposed change-id? Mercurial has "topics", which I don't know too much about. Even if such a "topic-identifier" were to be stored in the commit header, it probably shouldn't be called the same thing as the change-id header. Otherwise it becomes impossible to determine if a change-id header is supposed to identify an individual patch across its versions or associate it semantically with others. >> 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. Well, if rebase is just a bunch of cherry-picks, that sounds like an implementation detail. The ways rebase and cherry-pick are most often used are semantically very different from each other. (interactive) rebase is often used to amend commits that already have descendants. In that case, it makes sense for the change-id to be preserved. cherry-pick on the other hand is often used to create a dublicate of a patch at a different location in the commit tree, e.g. for backporting purposes. The equivalent of cherry-pick in Jujutsu is called "duplicate" and doesn't preserve the change-id for that reason. So if cherry-pick retains the change-id, that would lead to more duplicate change-ids in the tree, degrading their usefulness in those cases for little benefit. But again, if Git decides to go that route it's still better for the other projects than not supporting the header at all. Remo
