Martin von Zweigbergk <martinvonz@xxxxxxxxxx> writes: > On Tue, 22 Apr 2025 at 15:42, Junio C Hamano <gitster@xxxxxxxxx> wrote: >> >> "Remo Senekowitsch" <remo@xxxxxxxxxxx> writes: >> >> > Btw. since the thread was started, the implementation in Jujutsu has >> > been completed and I've been pushing commits with the change-id header >> > to various remotes for a while now. It works well. Forges can start >> > taking advantage of it. (I hope I find time to help work on that.) >> >> It should work well, until somebody finds your random is not random >> enough, right? Unlike our object name that depends on the contents >> (hence a duplicate unless the cryptographic hash function collides >> means they are truly the same commit), there is no grabally unique >> ID assigner involved in your implementation, right? > > A forge can decide to enforce that no two commits on the main branch > have the same change ID, for example. Would it make sense, though? Imagine that a contributor in your project did not refactor code properly and instead made a copy-and-paste duplicates of a very similar code. I find a bug in one of them, without realizing that the old mistake of duplicating code (instead of making it a shared helper that is called from the two places) and create a fix for it. Later somebody else realizes the same fix is needed for the other copy---attempting to cherry pick the original fix may find that remaining copy of a buggy code as the logic to perform a three-way merge across renames that is sufficiently clever kicks in. Shouldn't these two commits to fix the same bug in two places share the same change ID so that it is clear to the later developers that the latter fix was derived from the former one?
