Martin von Zweigbergk <martinvonz@xxxxxxxxxx> writes: > 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`. If we limit the data model so that it cannot represent one commit becoming split into two (or vice versa), and instead one old commit always corresponds to one new commit, our design of convenience operations may become a lot easier and simpler. No question about that. I am not sure that is not like a tail wagging a dog, though. If most use cases are one-to-one without split/merge, then you can still perform operations that require one-to-one correspondence in most cases where "predecessor pointer" and "change ID" are moral equivalents, no? In any case, that wasn't what I primarily was interested to talk about. It sounds like the "change ID" being discussed is a simple and useful thing that can and should be a commit trailer that is carried forward automatically across "git commit --amend", "git rebase", and "git cherry-pick", i.e. those commands that duplicate a new copy, a refinement, of an existing commit object, without any additional support from Git proper. More importantly, unlike the "predecessor" thing, which may be helped if Git knew that it can optionally affect reachability, it does not look like it needs any meaning that needs structural support from Git internals. So I do appreciate that the wider Git ecosystem like Gerrit and JJ are talking to adopt "Change ID" with the same syntax and semantics (if they all can agree, that is), but I do not think it needs to affect Git at the object level. From what I have heard so far, it certainly does not fit in the commit and tag object headers, but more like the usual trailer thing.
