On Wed, 23 Apr 2025 at 08:51, Junio C Hamano <gitster@xxxxxxxxx> wrote: > > 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? Maybe it depends on how the forge uses the change id. If the forge is Gerrit, it will use the (change id, target branch) to identify a review (IIUC), so then it will require a new change ID because it requires a new review. If it doesn't have that requirement (maybe it's PR-style forge), then it could at least highlight to the reviewer that there was an old version of the change that has already been merged. As Remo said, we've implemented this feature in Jujutsu and we'll probably enable it by default soon. I think GitButler has had it enabled for quite some time. So maybe we'll see in a year or two what problems it causes :)
