On Wed, Apr 9, 2025 at 12:56 PM Nico Williams <nico@xxxxxxxxxxxxxxxx> wrote: > > On Wed, Apr 09, 2025 at 08:19:24AM -0400, Theodore Ts'o wrote: > > On Tue, Apr 08, 2025 at 10:53:06AM -0500, Nico Williams wrote: > > > I'm not keen on CR tools "intuiting" from.. similarity checks. > > > [...] > > > > I'm not keen on fields that can have essentially random semantics. > > Part of this is because today Change-ID is in the footer, and so > > humans can randomly set it to any value they like. Sometimes they cut > > and paste footers, and so completely unrelated commits have the same > > Change-Id which show up when you do a Gerrit lookup by Chnage-Id. > > Admittedly, this aspect gets better if we shove it into the git commit > > header. > > > > Part of it is because some tools will edit the Change-Id when doing a > > cherry-pick. [...] > > I was only proposing to leave some details out, not to have completely > undefined semantics. The particular details we might want to leave out > are about resolving change IDs to URIs. In particular this editing of > change IDs on cherry-pick you mention has to not be permitted, or > perhaps a new change ID could be added -- i.e., are these headers > single-valued or multi-valued? > > Let's nail down the semantics of these change ID headers. Here is a > proposal to bang on: > > - change IDs get preserved on cherry-pick and on `pick`s in rebases > > - users can manually remove or change these change IDs, naturally, > though generall they would not > > - the actual change IDs are either free-form or they are URIs -- pick > one, but if they are URIs they should be URIs to CRs, and approved > CRs should perhaps have links to integration reports etc. Using URIs [to code reviews] looks to me like it makes some assumptions about what creates or consumes these headers, right? Especially since the URI should point to a code review… Is there a way to do that which is downstream-agnostic? Further, and maybe this is my ignorance of Gerrit showing: how would you attach a URI to a local commit when authoring it? You don't have the review URI when running `git commit`, do you? (Maybe I misunderstood; I'm seeing an odd chicken-egg problem here.) Which begs another question: what/who applies the initial change ID to a commit and when? […] I've skimmed most of the discussion, and I think a unique ID for an in-flight series could be useful for ergonomics and to support more tools that link between versions of the series. 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 Cheers, D. Ben Knoble PS This discussion feels somewhat related to the classic GitHub problem of not presenting interdiffs/range-diffs: GitHub shows a too-flat source diff on force-pushes. Perhaps better web UI tooling about interdiff review (which I think is one of the things Gerrit does/wants to do?) makes change IDs less necessary, since interdiffs help connect evolutions of commits?
