On Thu, 3 Apr 2025 at 19:40, Elijah Newren <newren@xxxxxxxxx> wrote: > > One possible simple solution here is just to treat change-ids (or > there abbreviations) kind of like abbreviated hashes -- they aren't > guaranteed to be unique. If the user specifies a change-id and there > are multiple branches with such a change-id, we provide the user an > error much like we do for abbreviated hashes. > > Is that what folks have in mind? If so, I'll be happy to drop my > reservations about this aspect. Yes, that's close to what we have in mind. I think I just didn't explain clearly that it's mostly harmless in at least Jujutsu if there are multiple commits with the same change id. If there are multiple visible commits with the same change id, then you'll just have to decide what should happen when the user tries to refer to commits by change id. We currently let it resolve to all the visible commits with the given change id. We may change that to be an error instead [1]. The user can always fall back to using the commit id in such cases. We call change ids with multiple visible commits "divergent". They currently show up in red in `jj log`, which I think we all agree makes them seem unnecessarily scary. We'll probably change that soon [2] [3]. So when I said that I think it's quite uncommon to have multiple commits with the same change id, I didn't mean that as an excuse to not consider the other cases at all. I just mean that I think the vast majority of commits are not cherry-picked, so we don't need to optimize the user experience for that case - it's fine if it's a bit more complicated to refer to such commits. I hope that clarifies. Let me know if there are still unanswered questions that I have missed. [1] https://github.com/jj-vcs/jj/issues/5632 [2] https://github.com/jj-vcs/jj/pull/5800 [3] https://github.com/jj-vcs/jj/pull/5850
