On Mon, 12 May 2025 at 10:03, Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Martin von Zweigbergk <martinvonz@xxxxxxxxxx> writes: > > > If we instead had something like Mercurial's Changeset Evolution > > (explicitly recording how commits have evolved), then we could have a > > similar identifier that was based on the original version of a commit. > > To make lookup by this kind of change ID faster, we could have an > > index from commit ID to change ID (i.e. original commit ID). This > > seems to imply a commit can have 0 or 1 predecessors (0 for brand new > > commits, 1 for rewrites), which is different from Mercurial's > > Changeset Evolution, but not necessarily bad. For this kind of change > > ID to be the same across repos, and assuming the predecessor pointer > > is stored in the commit, we need to make sure to transfer all commits > > back to the original commit when we push to a remote. As I think we've > > talked about before here, that can be problematic because the user has > > to be careful to check that the intermediate commits did not have > > anything sensitive in them. It's also often wasteful to share all the > > intermediate commits with other developers. Another option is to > > transfer the predecessor pointer outside of the commit object. That > > has its own problems, like being able to create cycles in the > > predecessor graph. > > A few comments (not necessarily strong suggestions). > > - I do not think you need to limit the predecessor pointers to 0 or > 1; when you started from N commits and worked to produce the > final single commit, the result would naturally have N predecessors. > > - The predecessor pointers do not necessarily have to participate > in the object transfer, just like filtered/lazy clones can ignore > the tree pointer in a commit object when making a commit-only > clone and the contained trees are fetched from the promisor > on-demand. It can even be set to be filtered out by default, > since it would make unnecessary transfer cost people would not > care most of the time, and only made available when the user > expresses that they want to know how the change resulted in the > current shape. Sorry, what I meant that those two things (limiting it to 0 or 1 predecessor and transferring predecessors to the remote) would be needed if you want to be able to use the predecessor pointers to infer a "change ID" that allows you to do things like `jj describe qx -m 'new description'; jj new qx`. Oh, I suppose the former can be relaxed by simply saying that the change ID is defined as (or derived from) the last commit ID you reach by walking predecessors backwards by following the first predecessor pointer if there are several. You still need to transfer at least that whole chain to the remote if you want to make sure that others agree about the change ID (though you only need to transfer the chain of first predecessors).
