On Sat, May 10, 2025 at 3:32 PM D. Ben Knoble <ben.knoble@xxxxxxxxx> wrote: […] > > Thanks for thinking out some concrete options on where IDs come from! > I think I've gotten even more confused on how they are supposed to be > used (which should probably inform the implementation), but hopefully > we're getting somewhere :) > > -- > D. Ben Knoble [Trying to summarize?] On a re-read of https://lore.kernel.org/git/CANiSa6gwup5vXU235mG+Ybbc+P=SbwoNFEmuhg=iYu0yGvSXVA@xxxxxxxxxxxxxx/, I see that change IDs were motivated partly by identifying (related?) commits after rewrites. I can certainly see how it would be nice to track down how a commit I'm working on evolved; I can even imagine most of the problems brought up in this thread wrt splitting or combining commits (not to mention, say, cherry-picks where the committer makes non-trivial changes to the patch). There was also a note about using a change ID to identify a code review in supporting tools. Neat! I'll leave it to someone else to summarize the open questions? (I now have a few of my own about how tools in Gits ecosystem respond to… unexpected… headers.) In the meantime, I think I'll repost this, since I'm not sure I ever got clarity: Re-reading the original post [1] (which didn't mention this kind of ID?), I'm having a hard time seeing the problem statement. There's a lot said here about the specifics of the solution, and some other neat things it might unlock… meanwhile, I'm wondering if all the consternation about change IDs is because the problem being solved is underspecified for a core Git feature? (That might tie to Ted's initial concerns about semantic meaning, on which I think I concur: the parent and committer/author headers have unambiguous meaning to Git, independent of anything else.) It looks to me, an outsider, like the problem is some combination of "I want to track a commit's evolution" and "I want to see related commits in review, esp. when it's an identical and already-approved commit." But I might be misreading, and clarifying the problem statement might help bring us to a better core solution? [1]: https://lore.kernel.org/git/xmqqh62tm5fo.fsf@gitster.g/T/#m038be849b9b4020c16c562d810cf77bad91a2c87 -- D. Ben Knoble
