I'll try to join some of our threads and summarize... please correct me if you disagree with that summary (or I've left something out you think is important). One of my points was that rebase usually doesn't lead to multiple visible commits with the same change-id, whereas cherry-pick usually does. You pointed out that rebase can in fact lead to multiple visible commits with the same change-id and cherry-pick sometimes doesn't (and some of these examples represent valid use cases). So making these two commands behave in a different way that only makes sense in the "common" case makes them more complicated - and less consistent - in the general case. I find this convincing and I now agree that both cherry-pick and rebase should preserve the change-id by default. The Gerrit developers will be happy about this anyway, and it's worth repeating that Jujutsu can deal with it perfectly fine while preserving almost all benefits of change-ids. When discussing the uniqueness of change-ids or lack thereof, I'd like to introduce one more factor: At which point in time during the development cycle a change-id is unique. Jujutsu users derive most of the benefits of change-ids during active development. The use case you find most important - tracking (forward- and) back-ports - happens at a different time during development, when a change has been merged to a public branch already. So I think there is no conflict at all. Change-ids will naturally tend to be unique during active development and once they are merged, whether the change-id stays unique or not doesn't matter anymore for those active development use cases. We can have our cake and eat it too. Remo
